SNAT irule doesn't match for a FastL4 VS for an IPSEC VPN
Hi everybody, I have a problem to bring up an IPSEC Tunnel between 2 firewall with one of them behind an F5 BIGIP. What I did : Create a VS FastL4 (Source Address 0.0.0.0/0, Destination Address my_public_ip_used_for_the_vpn, Service port All_Ports, Protocol All, Source Address Translation NONE). For the SNAT I tried to use a SNAT POOL For the SNAT I tried to use an iRule : when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 10.199.0.1/32] } { snat X.X.X.X.85 nexthop X.X.X.X.1 log local0. " -- SNAT VPN IPSEC S2S -- [clientside {IP::remote_addr}]:[clientside {TCP::remote_port}] to [clientside {IP::local_addr}]:[clientside {TCP::local_port}]" } } For the SNAT I tried to use GUI : In all case the F5 doesn't take my SNAT rule and the traffic take another public IP. On the peer device (which is not behind an F5) I have a log "Asymmetric Routing". It's normal because he tries to establish the tunnel with an IP and there is another IP that respond to him. On the F5 I can see it on the logs 16:30:36.409542 IP Y.Y.Y.Y.isakmp > X.X.X**.85**.isakmp: isakmp: phase 1 I ident 16:30:51.939720 IP 10.199.0.1.isakmp > Y.Y.Y.Y.isakmp: isakmp: phase 1 I ident 16:30:51.939732 IP X.X.X**.251**.20251 > Y.Y.Y.Y.isakmp: isakmp: phase 1 ? ident The peer device seems to successfully contact my firewall on Y.Y.Y.85 but the F5 respond with the Y.Y.Y.251 Is there anything that I forgot in the configuration?
Explicit Forward Web Proxy, forward proxied traffic over IPSEC terminated on F5 to remote device.
I have succesfully set up an IPsec tunnel between the F5 and remote device. I have HTTPS server configured on the remote end and on a client I able to connect to the HTTPS server when using the F5 internal interface as the default gateway on the client. I have succesfully set up the explicit forward proxy and when I configure the client to point to the virtual server I am able to proxy web traffic out to the Internet. (Bypassing the IPsec tunnel and going to the Internet) However I am not able to force the proxied traffic over the IPSEC tunnel succesfully to reach my HTTPS server on the remote end.
F5 Not Functioning With Pulse Secure
Hi All, We have a new set-up of an F5 with two VIPS - one performance layer 4 for https (SSL authentication to the pulse secure appliance), ad another standard VIP on UDP/4500 (for IPSec data traffic). Both Profiles have a source affinity persistence profile mapped to them which has option "Match Across Virtual Server" checked. This is to allow Both VIPS to act as one for Data Traffic. The F5 has also two Gateways configured as self IP's and their respective floating IP's - this is so the pulse uses the F5 as its gateway for internal and external traffic. The routing on the F5 points internal traffic to a default route to a switch in the DMZ which knows the route to the data center - and was being used to route traffic in the old set-up too. What we found with the new set-up was that traffic going to the external port worked fine, but traffic to the internal port on the pulse (routed via the F5 internal gateway) was not working at all. This interface should use its own IP address and initiate a request to Authentication servers, but did look like it was - resulting in users not being able to log into their pule clients (as authentication was failing). In the old set-up the gateways were on two separate switches, and this worked even after we reverted back - we saw users able to connect and log into pulse - where as in the new set-up they couldn't go past the prompt. We believe the issue is only with internal traffic, as external traffic looks fine. We also believe it could be the F5 potentially stopping the traffic from passing but not sure why. Could the profile be changing something in the packet header? Could both VIPs also need to be standard VIPS for this to work ? Has anyone come across an issue like this before ? Best Regards, Sabeel
IPSec VPN - Must the tunnel local address be the self/floating IP address?
Hello everyone, Regrading IPSec VPN (tunnel mode) setup, I have no idea whether the tunnel local address can be different than the self/floating IP address (another IP address in the same range with self/floating IP address) or not, but I noticed this when I was working on a F5 BIG-IP system. For example, the self and floating IP addresses are a.b.c.200/25 and a.b.c.202/25, respectively, but the tunnel local address is a.b.c.199/25. However, when I checked the system configuration, I could not find the IP a.b.c.199/25 assigned or associated to any interfaces/VLANs, but only ltm nat-translation, snatpool (for IPSec local encryption domain - private network) and a few rules for ESP/IKE packets. Additionally, I could ping this IP address from the BIG-IP system.
Connection not getting ACK in 3way handshake in IPSec
Hi, We have a minor IPsec problem and I can't seem to wrap my head around it. There a number IPSecs on our F5 and most of them have public IP addresses assigned to them and public peers as well. But this one is using private IP addresses and is going through an MPLS VPN cloud. So something like this: Remote FW <-> Cisco ASR where the other end of the IPSEC is terminated <-> PE router of the MPLS <-> MPLS <-> Another PE <-> Our F5 LTM/AFM device On our end, we have a VLAN configured which floating IP is the one terminating the IPsec. Also, this VLAN is a transit VLAN, an incoming/outgoing interface from/to the MPLS cloud. The traffic from our end goes like this: 10.78.69.140 -> 10.30.0.74:443 The 10.78.69.x subnet is assigned to a forwarding virtual server that can send traffic anywhere, including the IPsec tunnel. So the problem is that the packet goes out but during the 3way handshake we can not see the ACK in the inside VLAN but we can see it in the incoming VLAN. tcpdump from the inside vlan that goes out on the outgoing forwarder: 15:56:24.329348 IP (tos 0x0, ttl 64, id 5505, offset 0, flags [DF], proto TCP (6), length 52) 10.78.69.140.25270 > 10.30.0.74.https: Flags [S], cksum 0xb05f (correct), seq 2546182054, win 26400, options [mss 1320,nop,nop,sackOK,nop,wscale 7], length 0 in slot1/tmm5 lis=/PART_XY/FWVS_XY-OUTSIDE incoming: 15:56:24.333293 IP (tos 0x0, ttl 125, id 28012, offset 0, flags [DF], proto TCP (6), length 52) 10.30.0.74.https > 10.78.69.140.25270: Flags [S.], cksum 0xa0b4 (correct), seq 3594223601, ack 2546182055, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 in slot1/tmm5 lis= So it seems that the for some reason the ACK can't be seen in the VLAN where the traffic was originated from. We've never had this kind of issue with the rest of the IPSec, even if the only difference is the IP address.. I'd appriciate if you could help me. Best regardsIPSec on F5-Cisco
Hi, this F5 article describes how to configure the F5 side of it on an IPSec tunnel between an F5 and a third party [Cisco ASA device]: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-implementations-11-4-0/19.html It says that the Virtual Server will have 0.0.0.0 IP address, and listening on All ports. My question is: If I configure that on the external VLAN of my F5 where I have more VSs on that VLAN, Will not that "All-the-IPs" [0.0.0.0] gobble up any traffic coming in to the F5 from the front end? What about replies to ARP? will it not mess up any ARP request, replying with ARP saying the F5 is what other server means to be?
LTM 13.0 Unable to create IPSec with traffic domain other than 0
Two F5 LTM VE systems. upgraded to 13.0 The goal is to create IPSec Tunnel when traffic selector is at non-0 Route Domain. IPsec tunnel works(ed) with only route domain 0. There are: 1. Two interfaces - Untagged, External with Public Self IP and tagged Internal with RFC 1918 Self-IP IP address 2. VLAN on on tagged interface (just one for testing) on both systems created on tagged interface 3. Route domain 0 is associated with Public Self IP/external interface 4. Route domain 1 is associated with Private Self IP/VLAN It is possible to ping both public IP and private IP for each system in the corresponding networks. When creating traffic selector end adding %1 (route domain ID) at the end of Source IP address following message is received: 01070734:3: Configuration error: Source address and destination address cannot be in different route domain When adding %1 both to source and destination IP addresses at the traffic selector, different message is received 01070734:3: Configuration error: Traffic selector (/Common/ZRHPAL_SEL) and IPsec policy (/Common/ZRHPAL_TUN) cannot be in different route domain We are stuck here. Please help. It worked without route domains, but we will need to use route domains and VLANs in the deployment.
