Forum Discussion
NimbostratusHow can I do a IPSEC VPN
In principle, the BIG-IP will interoperate with ASA devices running current ASA software and a current TMOS versions. It is frequently done in fact, but requires patience and sometimes assistance from F5 Support. IPsec is hard to wrap your head around.
Both IKEv1 and IKEv2 are supported when bringing up BIG-IP tunnels to an ASA, although you really do want to be running the latest version of 13.1. For an ASA interop, right now I'd recommend starting with IKEv1. Disclaimer: Most vendor specific Vendor IDs are not supported by the BIG-IP.
Unless you're configuring a BIG-IP in the Cloud (Azure/AWS/Google) then I recommend you configure your IPsec Policy (net ipsec ipsec-policy) to use "Tunnel" mode. Do not use "Interface" mode, it is more complex to configure and is useful only for very specific solutions. From the ASA's perspective it won't have a clue whether you've selected Interface or Tunnel mode and it is not part of the ISAKMP negotiation (tunnel setup).
Following a guide like this should be fine: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-implementations-11-5-0/17.html
It takes the assumption that you are configuring two BIG-IPs as peers, so just pretend that "BIG-IP B" is the ASA!
That manual chapter is missing one important point. If you don't have a default route, or you have multiple gateways, you need to configure a static route for (1) the next-hop to the remote peer's public IP and (2) the next-hop to the remote peer's private network. If I recall correctly, the ASA has a similar requirement. The next-hop IP for both route (1) and (2) will be the same IP. Yes, you read me right, tell the BIG-IP that the route to the private network is via your ISP next-hop.
Don't forget that if either side is behind a NAT, then enable NAT detection.
I recommend that you do not try pinging from the BIG-IP, in case that's what you are trying. PING from a host that is inside the local private network to the remote private network. In other words, the PING must be between two hosts that have IPs covered by a traffic-selector (tmsh list net ipsec traffic-selector).
If you are pinging between two real hosts, then make sure that you have a Virtual Server that allows ICMP. If you have a wildcard (0.0.0.0:*) Virtual Server, then that will handle the traffic. There must be some Virtual Server that handles the private traffic, just like any other traffic. The Virtual Server needs to listen on at least the internal VLAN so that connections to the remote can be established from the BIG-IP side. If such a Virtual Server doesn't listen on the external VLAN then new connections coming from the remote (over IPsec) cannot be established. Remember that a Virtual Server configured to listen for a specific destination might not match both directions of a traffic-selector. Therefore you might find that you can only establish connections from the BIG-IP side but not establish connections from the remote side.
Note: The Virtual Server does not handle IPsec or ISAKMP, only the private traffic.
A few troubleshooting ideas:
- Check that your Virtual Server(s) match the private traffic.
- Double check that you have at least a default gateway, per what I wrote earlier.
- You can tcpdump traffic on the BIG-IP of course, to see whether the inbound (PING) traffic is matching your selectors and look for ESP packets.
- Use "tmsh show net ipsec traffic-selector" to see whether there are any packet counters on the traffic-selectors either IN or OUT.
- In "tmsh show net ipsec ipsec-sa" you should see the SAs as being "mature" and not "larval" for example.
