ipsec
27 TopicsMultiple IPSec tunnels to the same remote peer
Hello everyone, I need to load balance traffic to a third party with IPSec. I have configured an IPsec tunnel using the IPSec Interface mode, assigning a /30 self-ip to the tunnel and creating a virtual server that forwards the traffic to the node with the tunnel remote IP. All this setup works as expected but the IPSec tunnel has a bandwidth limitation of 1Gbps and I need to reach 3Gbps. The problem that I am facing is: when I try to create a new ike-peer with the same destination IP address, I get the error: 01070734:3: Configuration error: remote-address (a.a.a.a) is also used by ike-peer (/Common/peer1) Does someone know how can I create multiple ipsec tunnels to the same remote IP? I can add different IPs in the local site, but not in the remote one. Regards and thanks in advance472Views0likes6CommentsSNAT 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?304Views0likes0CommentsExplicit 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.795Views0likes2CommentsF5 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, Sabeel1.1KViews0likes1CommentIPSec 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.891Views0likes1CommentConnection 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 regards539Views0likes0CommentsIPSec 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?816Views0likes11CommentsDuring ike rekey in a s2s IPsec config some tunnels won't reestablish
Hi, I would like some help regarding an IPsec problem we are experiencing in our DC. We have a few different route domains in our F5. Two different RDs are configured for IPSec to two different remote sites. The only thing common between the two connections is that both remote device is a Cisco ASA. One is an ASA5520 on 7.2(4) and the other one is an ASA5585 on 9.2(4)14. Here are the details of the IPsec configuration: PHASE1 Version:IKE v1 Authentication algorithm:SHA-1 Encryption algorithm:AES256 Perfect forward secrecy/dh-group:MODP1536 Lifetime:1440 Authentication method:PSK Mode:Main NAT Traversal:ON DPD Delay:30 sec Replay window size:64 packets PHASE2 IPsec protocol:ESP Mode:Tunnel Authentication algorithm:SHA-1 Encryption algorithm:AES256 Perfect forward secrecy:MODP1536 Lifetime:1440 It has been verified by both sides multiple times that the configuration is exactly the same. Also, we are the ones using NAT-T. We have an external router where the public ip address is NATed to the F5. The problem is that during ike rekeying some tunnels won't reestablish. Only some will, but not all. For example in one ipsec there are 3 traffic selectors. Traffic is flowing through in all 3 of them when everything is fine. After the rekeying only one will work and we have to clear the whole ipsec to make it work again. What we found so far that the ASAs will start rekeying at 75% of the lifetime (so in our case around 18 hours) https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.htmlvpndisc According this document it's not a problem. However, almost always the tunnels won't come up. (There have been a few occasions when for some magical reason they came up but it's pretty rare..) Log from the ASA when rekeying starts at 18 hours. Mar 7 02:50:51 asa %ASA-4-113019: Group = 1.2.3.4, Username = 1.2.3.4, IP = 1.2.3.4, Session disconnected. Session Type: IPSecLAN2LANOverNatT, Duration: 18h:00m:29s, Bytes xmt: 4133553397, Bytes rcv: 2396963220, Reason: IKE Delete Here are the logs from the racoonctl log, as it is too long to paste it here: https://pastebin.com/H39ZbYLS So the conclusion so far is that there is traffic between the peer IPs, even when the problem occurs. The traffic in the IPsec SAs goes back and forth continuously. When the IKE rekey happens the old IKE SA closes and a new one is created and the IPsec SAs are renewed. For a second the traffic in the IPsec SAs breaks but then continues to flow once again. But when the error happens not every IPsec SA reestablishes and we can only see timeouts in the logs. I hope you can help. The clients are a "bit" mad about this issue. Thanks.Solved2.9KViews0likes1Comment