Forum Discussion
IPSec on F5-Cisco
I don't recommend using a wildcard virtual server to handle IPsec traffic because of the security implications.
It's better to create a Virtual Server that handles the specific private subnets. You might have to create a Virtual Server for each direction, otherwise traffic cannot be established in both directions unless your local and remote private networks were both in 10.0.0.0/8 for example, then in that case one VS can cover traffic being established in both directions.
In the two Virtual Server scenario, one needs to listen on the internal side VLAN and the other needs to listen on the public side VLAN. In the one Virtual Server scenario, for bi-directional connection establishment, it needs to listen on both the internal and external side VLANs.
Remember that the Virtual Server does not actually handle the IPsec (ISAKMP and ESP) it handles the private network traffic.
- a_basharatJul 19, 2018Nimbostratus
I am absolutely agree with the security concerns of using a Wildcard VS and listening on all ports, but it is F5 who published it officially in their deployment guide: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-tmos-tunnels-ipsec-13-1-0/10.htmlguid-4a5c2cee-039b-489f-9d78-3e0708491c67
Is there any light guide of how to do it with specific VSs, listening on specific IP Addresses, what port or range of ports will be needed? where to configure those VSs [frontend, backend]?
- zeiss_63263Jul 19, 2018Historic F5 Account
Getting a solution working with a wide open Virtual Server is a reasonable plan as a first step in working on the configuration, but after implementation is shown to work, the Virtual Server could be locked down to match traffic-selectors as tightly as possible. Outside of matching the inner (private) IPsec traffic, a wildcard Virtual Server may be handling completely unexpected types of traffic, unrelated to the IPsec traffic.
Here's a config example of configuring two BIG-IPs, each with two Virtual Servers for one specific tunnel. Assume the tunnel is between 10.20.131.0/24 <-> 10.10.131.0/24.
bigip1
tmsh create ltm virtual ipsec-131-encap { destination 10.20.131.0:any ip-forward mask 255.255.255.0 source 10.10.131.0/24 profiles add { fastL4 { } } vlans add { vlan_internal } vlans-enabled }
bigip2
tmsh create ltm virtual ipsec-131-decap { destination 10.20.131.0:any ip-forward mask 255.255.255.0 source 10.10.131.0/24 profiles add { fastL4 { } } vlans add { vlan_external } vlans-enabled }
At this point note, if a flow was initiated by the host on bigip2 to the host on bigip1, the connection would not work. On bigip2, the flow will not match any existing connection and there is no Virtual Server listening to this traffic 10.20.131.1 -> 10.10.131.1. So it is necessary to make a second Virtual Server on both BIG-IP devices to facilitate two-way traffic initiation.
bigip1
tmsh create ltm virtual ipsec-131-decap { destination 10.10.131.0:any ip-forward mask 255.255.255.0 source 10.20.131.0/24 profiles add { fastL4 { } } vlans add { vlan_external } vlans-enabled } bigip2: Add encapsulating-side side Virtual Server
bigip2
tmsh create ltm virtual ipsec-131-encap { destination 10.10.131.0:any ip-forward mask 255.255.255.0 source 10.20.131.0/24 profiles add { fastL4 { } } vlans add { vlan1555 } vlans-enabled }
One final note, not all types of virtual servers and not all types of profiles will work for IPsec traffic. Stick with the ip-forward.
- a_basharatJul 19, 2018Nimbostratus
On "IPsec traffic selector", I have three local Networks like:
10.15.93.0/24, 10.15.60.0/24 and 10.15.87.0/24 on the "Source IP Address or CIDR" but just one on the "Destination IP Address or CIDR"
That means three traffic selectors or can I combine all the source IP Addresses in one line and one traffic selector?
The default value for Order setting is "Last" on the F5, but "First" on the F5 deployment guide, How to marry them up?
- zeiss_63263Jul 19, 2018Historic F5 Account
You could create a "10.15.0.0/16" <-> "remote net" selector, or three separate ones if you wish. The Virtual Server approach would be the same. The "order" parameter no longer has any meaning, so it doesn't matter what you put there.
You could probably use a /17 netmask if you wanted to be really clever.
$ ipcalc 10.15.0.0/17 Address: 10.15.0.0 00001010.00001111.0 0000000.00000000 Netmask: 255.255.128.0 = 17 11111111.11111111.1 0000000.00000000 Wildcard: 0.0.127.255 00000000.00000000.0 1111111.11111111 => Network: 10.15.0.0/17 00001010.00001111.0 0000000.00000000 HostMin: 10.15.0.1 00001010.00001111.0 0000000.00000001 HostMax: 10.15.127.254 00001010.00001111.0 1111111.11111110 Broadcast: 10.15.127.255 00001010.00001111.0 1111111.11111111 Hosts/Net: 32766 Class A, Private Internet
- a_basharatJul 19, 2018Nimbostratus
I ended up, putting multiples "traffic selector", all of them with same order [1], but as you said that doesn't matter as it will take it anyway.
The "direction" of a traffic selector is quite important to me, there are three options: In, Out, Both -> "In" means from "Source IP Address or CIDR" to "Destination IP Address or CIDR" or is it the other way round?
- zeiss_63263Jul 19, 2018Historic F5 Account
You can find context sensitive help on configuration parameters. The web UI states "Specifies whether the traffic selector applies to inbound or outbound traffic, or both. The default value is Both."
If you want bi-directional traffic then, for each local and remote network pair, you need one traffic-selector set to "both". In your case it sounds like you want three traffic-selectors set to "both".
- a_basharatJul 19, 2018Nimbostratus
I am trying to avoid Both [bidirectional] as the requirement from the client is unidirectional from "Source IP Address or CIDR" to "Destination IP Address or CIDR" : That will be In or Out? as I found the help tab not very clear on this
- zeiss_63263Jul 19, 2018Historic F5 Account
In means packets arriving to (inbound) the BIG-IP. Out means packets leaving (outbound) the BIG-IP. You would also not need to write Virtual Servers to cover both directions, only the direction for which the connection is being established.
- a_basharatJul 19, 2018Nimbostratus
Ok, still a bit iffy for me. Let me ask you with other words:
- A packet from the Network hanging off the F5 to the Network hanging off the remote ASA is OUT?
- A packet from the Network hanging off the remote Cisco to the Network hanging off the F5 is IN?
Let me know please
- zeiss_63263Jul 19, 2018Historic F5 Account
I think you understand correctly. IN literally means packets coming into the BIG-IP over the tunnel. In IP routing this should only be packets with a source IP of the ASA side and a destination IP of the BIG-IP side.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com