VPN connection behind F5 Link controller

I was looking for a way to have the ASA's independently determine failure and transition to a new gateway.

Initially the engineers in my company and I built a pair of VS's that NATed a remote ASA. When this didn;t work as expected I traced the comms on either side and noticed that the F5 was sending an ICMP host unreachable, port unreachable back from the SNAT address associated with the Virtual server, when the ASA's were shifting to udp port 4500 for the NAT-T. This was in spite of an existing connection in the conn table that showed the mapping in a manner we would expect.

The solution we used (for now at least we are still playing around with it) was to create a new pair of virtual servers using the SNAT interface IPs from the original VS's (Standard VS UDP port 4500) in the reverse direction.

This allowed the return traffic to flow back to the original ASA and a tunnel successfully established.

It seems strange though, the IKEv1 traffic flowed back and forth with a single VS, there was no need to map another in the reverse direction.

However when the originating ASA sent port 4500 traffic (the continuation of the Phase 2 setup wrapped in a udp tunnel) the traffic made it to the remote ASA, but when the Remote responded in kind we observed the port unreachable error coming form the F5.

This lead to the creation of the reverse direction VS's.

This does not seem an elegant solution, but it does work.

Hi guys,

We have some setups following some of the suggestions presented here, including the need of special VSs, like 500.

Also we had dealed with IPSECv1 and IPSECv2 Site-to-Site VPNs, L2TP, IKE, SSL client-to-site VPNs.

One related matter that still bothering us is the Check Point SSL Network Extender client for Linux. It´s a compiled program using OpenSSL and other stuff that requests some HTTPs URLs from VPN-1 Gateway and parses it´s replies searching for special var=values pairs.

Even on R77.10, checkpoint does not have, or i havent found it yet, way to set the gw_ip that´s replied to SNX for Linux telling that it does use a NATed IP to recieve connections behind a NAT FW or F5. This option should follow IPSEC->Link-Selection->Incomming option for Site-to-Site VPNs or the GuiEdit fun part for RemoteAccess (basically setting RA-like variables thru the CheckPoint internal "registry" which are not yet avaliable at SmartDashboard gui).

So, back to F5 world, we tried :

ltm pool /Common/pool_vpngw_443 { members { /Common/172.NN.XX.200:443 { address 172.NN.XX.200 } } monitor /Common/tcp_half_open } ltm virtual /Common/vs_vpngw_443 { destination /Common/177.NN.XX.8:443 ip-protocol tcp mask 255.255.255.255 pool /Common/pool_vpngw_443 profiles { /Common/fastL4 { } } source 0.0.0.0/0 translate-address enabled translate-port enabled vlans-disabled }

And the SNX fails when stablishing the last part before openning the ssl tunnel ´cause it recieves the VPN-1 Gateway external IP, which is reserved One.

Changed VS to

ltm virtual /Common/vs_vpngw_443 { destination /Common/177.NN.XX.8:443 ip-protocol tcp mask 255.255.255.255 pool /Common/pool_vpngw_443 profiles { /Common/clientssl_lab_vpn-1 { context clientside } /Common/http { } /Common/tcp { } } rules { /Common/irule-sslvpn-linux } source 0.0.0.0/0 source-port preserve-strict translate-address enabled translate-port disabled vlans-enabled } ltm rule /Common/irule-sslvpn-linux { when HTTP_REQUEST { if {[HTTP::uri] contains "172.NN.XX.200"} { HTTP::uri [string map {"172.NN.XX.200" "177.NN.XX.2"} [HTTP::uri]] } } }

At Linux SNX client´s debug i could see that the gw_ip has changed, but the ssl tunnel could not be stablished.

Windows clients works from the start with original configuration.

Any1 have a solution for it ?