This post is an example of configuring an IPsec tunnel with F5 BIG-IP. In the diagram below the IPsec tunnel is configured between SRX210 (Junos 12.1X47-D20.7) and F5 BIG-IP (11.6.0 HF5-ENG11).
F5 BIG-IP is connected here in one-arm setup. The SRX240 is not “an interesting device” in this demonstration. It is just a firewall and a router in the site LAN. The public IP address of the F5 BIG-IP (198.51.100.10) is routed normally in the SRX240, there is no NAT for that connectivity. F5 BIG-IP uses SRX240 as the default route next hop.
Let’s first complete the SRX210 configuration on Site 1:
set interfaces st0 unit 2 description "IPsec tunnel to F5" set interfaces st0 unit 2 family inet set security ike proposal IKE_SHA256_AES256_DH14 authentication-method pre-shared-keys set security ike proposal IKE_SHA256_AES256_DH14 dh-group group14 set security ike proposal IKE_SHA256_AES256_DH14 authentication-algorithm sha-256 set security ike proposal IKE_SHA256_AES256_DH14 encryption-algorithm aes-256-cbc set security ike proposal IKE_SHA256_AES256_DH14 lifetime-seconds 86400 set security ike policy F5_TEST mode main set security ike policy F5_TEST proposals IKE_SHA256_AES256_DH14 set security ike policy F5_TEST pre-shared-key ascii-text ThisIsSecret set security ike gateway GW_F5 ike-policy F5_TEST set security ike gateway GW_F5 address 198.51.100.10 set security ike gateway GW_F5 no-nat-traversal set security ike gateway GW_F5 external-interface fe-0/0/2.0 set security ipsec proposal F5 protocol esp set security ipsec proposal F5 authentication-algorithm hmac-sha1-96 set security ipsec proposal F5 encryption-algorithm aes-256-cbc set security ipsec proposal F5 lifetime-seconds 3600 set security ipsec policy VPN_POLICY_F5 perfect-forward-secrecy keys group14 set security ipsec policy VPN_POLICY_F5 proposals F5 set security ipsec vpn F5 bind-interface st0.2 set security ipsec vpn F5 df-bit clear set security ipsec vpn F5 ike gateway GW_F5 set security ipsec vpn F5 ike ipsec-policy VPN_POLICY_F5 set security ipsec vpn F5 traffic-selector TS_1 local-ip 172.31.31.0/24 set security ipsec vpn F5 traffic-selector TS_1 remote-ip 172.17.73.0/24 set security ipsec vpn F5 establish-tunnels immediately
This IPsec configuration uses traffic selectors as described in my earlier post.
In the second site there is SRX240 as a firewall. It is not participating in the IPsec tunnel (other than allowing IKE+ESP through) but a static route is needed on it for the routing to work in Site 2:
set routing-options static route 172.31.31.0/24 next-hop 198.51.100.10
Why is this needed? Because the traffic coming from 172.17.73.0/24 and going to 172.31.31.0/24 would otherwise be routed to the Internet (via the default route) on SRX240. This static route directs it to the BIG-IP for IPsec encapsulation. So this is just a basic routing configuration.
Now let’s continue with the F5 BIG-IP on Site 2. First set up the IKE peer:
Some specific comments about these configurations:
- Perfect Forward Secrecy: F5 uses the MODP syntax for specifying the DH groups. MODP2048 = group 14. See for example Internet Key Exchange (IKE) Attributes from IANA for the full list of DH groups.
- Lifetime: This is minutes, not seconds. 1440 minutes = 86400 seconds.
Then set up the IPsec policy:
Again, the time-based lifetime is entered in minutes, not in seconds.
The final IPsec-related configuration is the traffic selector. Only one traffic selector is needed in this case:
Due to the traffic forwarding ideology of F5 BIG-IP (basically, it does not forward anything unless configured), we also need a forwarding virtual server for the tunneled traffic to work through BIG-IP:
You may want to customize it as you need. The purpose of this virtual server is to enable BIG-IP to process and forward the incoming packets as the BIG-IP is now basically used as a router.
As soon as the IPsec configurations were completed, the SRX syslogged this (line breaks added):
Jul 12 16:43:55 srx210 kmd[1508] IKE negotiation failed with error: Authentication failed. IKE Version: 1, VPN: F5 Gateway: GW_F5, Local: 203.0.113.2/500, Remote: 198.51.100.10/500, Local IKE-ID: 203.0.113.2, Remote IKE-ID: 127.0.0.1, VR-ID: 0
Meanwhile BIG-IP logged these in /var/log/racoon.log:
2015-07-12 16:43:55: INFO: respond new phase 1 negotiation: 127.0.0.1[500]<=>203.0.113.2[500] 2015-07-12 16:43:55: INFO: begin Identity Protection mode. 2015-07-12 16:43:55: INFO: received Vendor ID: DPD 2015-07-12 16:43:55: WARNING: SPI size isn't zero, but IKE proposal. 2015-07-12 16:43:55: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1. 2015-07-12 16:43:55: INFO: Send INITIAL-CONTACT to :203.0.113.2[500] 2015-07-12 16:43:55: INFO: ISAKMP-SA established 127.0.0.1[500]-203.0.113.2[500] spi:a5b74270c20eef8f:b94e0f24c366914d 2015-07-12 16:43:55: INFO: respond new phase 2 negotiation: 127.0.0.1[500]<=>203.0.113.2[500] 2015-07-12 16:43:55: INFO: best sp match: 172.31.31.0/24[0] 172.17.73.0/24[0] proto=any dir=in 2015-07-12 16:43:55: INFO: best sp match: 172.17.73.0/24[0] 172.31.31.0/24[0] proto=any dir=out 2015-07-12 16:43:55: INFO: ISAKMP-SA expired 127.0.0.1[500]-203.0.113.2[500] spi:a5b74270c20eef8f:b94e0f24c366914d 2015-07-12 16:44:05: ERROR: phase2 negotiation failed due to phase1 expired. a5b74270c20eef8f:b94e0f24c366914d:0000eb0f 2015-07-12 16:44:06: INFO: ISAKMP-SA deleted 127.0.0.1[500]-203.0.113.2[500] spi:a5b74270c20eef8f:b94e0f24c366914d
Clearly there is something wrong. Since SRX said “Remote IKE-ID: 127.0.0.1” something has to be done in BIG-IP.
Let’s go back to the IKE peer configuration and change the Presented ID settings:
Select Override in Presented ID and enter the system’s own IP address (actually the cluster IP address as this is a device cluster) in the value field.
That helped, the tunnel came up in SRX:
Jul 12 16:55:45 srx210 rpd[1502] EVENT <UpDown> st0.2 index 83 <Up Broadcast PointToPoint Multicast> Jul 12 16:55:45 srx210 kmd[1508] Local gateway: 203.0.113.2, Remote gateway: 198.51.100.10, Local ID: ipv4(172.31.31.0-172.31.31.255), Remote ID: ipv4(172.17.73.0-172.17.73.255), Direction: inbound, SPI: 0xa71aae87, AUX-SPI: 0, Mode: Tunnel, Type: dynamic, Traffic-selector: TS_1 Jul 12 16:55:45 srx210 rpd[1502] EVENT UpDown st0.2 index 83 <Up Broadcast PointToPoint Multicast> Jul 12 16:55:45 srx210 kmd[1508] Local gateway: 203.0.113.2, Remote gateway: 198.51.100.10, Local ID: ipv4(172.31.31.0-172.31.31.255), Remote ID: ipv4(172.17.73.0-172.17.73.255), Direction: outbound, SPI: 0x90ed5c76, AUX-SPI: 0, Mode: Tunnel, Type: dynamic, Traffic-selector: TS_1 Jul 12 16:55:45 srx210 kmd[1508] VPN instance-GT-F5_TS_1_268173315 from 198.51.100.10 is up. Local-ip: 203.0.113.2, gateway name: GW_F5, vpn name: GT-F5_TS_1, tunnel-id: 268173315, local tunnel-if: st0.2, remote tunnel-ip: Not-Available, Local IKE-ID: 203.0.113.2, Remote IKE-ID: 198.51.100.10, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: TS_1, Traffic-selector local ID: ipv4(172.31.31.0-172.31.31.255), Traffic-selector remote ID: ipv4(172.17.73.0-172. Jul 12 16:55:45 srx210 - srx210 ip_mon_reth_scan: interface st0.2 trigger reth_scan Jul 12 16:55:45 srx210 mib2d[1501] ifIndex 535, ifAdminStatus up(1), ifOperStatus up(1), ifName st0.2
And in BIG-IP:
2015-07-12 16:55:45: INFO: respond new phase 1 negotiation: 127.0.0.1[500]<=>203.0.113.2[500] 2015-07-12 16:55:45: INFO: begin Identity Protection mode. 2015-07-12 16:55:45: INFO: received Vendor ID: DPD 2015-07-12 16:55:45: WARNING: SPI size isn't zero, but IKE proposal. 2015-07-12 16:55:45: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1. 2015-07-12 16:55:45: INFO: ISAKMP-SA established 127.0.0.1[500]-203.0.113.2[500] spi:937b460c9efe69e7:c2694ed94cc8ad70 2015-07-12 16:55:45: INFO: respond new phase 2 negotiation: 127.0.0.1[500]<=>203.0.113.2[500] 2015-07-12 16:55:45: INFO: best sp match: 172.31.31.0/24[0] 172.17.73.0/24[0] proto=any dir=in 2015-07-12 16:55:45: INFO: best sp match: 172.17.73.0/24[0] 172.31.31.0/24[0] proto=any dir=out 2015-07-12 16:55:45: INFO: IPsec-SA established: ESP/Tunnel 203.0.113.2[0]->198.51.100.10[0] spi=2431474806(0x90ed5c76) 2015-07-12 16:55:45: INFO: IPsec-SA established: ESP/Tunnel 198.51.100.10[0]->203.0.113.2[0] spi=2803543687(0xa71aae87)
Statistics on SRX:
admin@srx210> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 2755214 UP 937b460c9efe69e7 c2694ed94cc8ad70 Main 198.51.100.10 admin@srx210> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <268173315 ESP:aes-cbc-256/sha1 a71aae87 3352/ unlim - root 500 198.51.100.10 >268173315 ESP:aes-cbc-256/sha1 90ed5c76 3352/ unlim - root 500 198.51.100.10 admin@srx210> show security ipsec security-associations detail ID: 268173315 Virtual-system: root, VPN Name: F5 Local Gateway: 203.0.113.2, Remote Gateway: 198.51.100.10 Traffic Selector Name: TS_1 Local Identity: ipv4(172.31.31.0-172.31.31.255) Remote Identity: ipv4(172.17.73.0-172.17.73.255) Version: IKEv1 DF-bit: clear Bind-interface: st0.2 Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29 Last Tunnel Down Reason: Delete payload received Direction: inbound, SPI: a71aae87, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2850 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2223 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: 90ed5c76, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 2850 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 2223 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits) Anti-replay service: counter-based enabled, Replay window size: 64
On BIG-IP, using tmsh this time:
admin@(f5-2000-1)(cfg-sync In Sync)(Active)(/Test-2)(tmos)# show net ipsec ipsec-sa IPsec::SecurityAssociations 198.51.100.10 -> 203.0.113.2 SPI(0xa71aae87) out esp (tmm: 1) 203.0.113.2 -> 198.51.100.10 SPI(0x90ed5c76) in esp (tmm: 1) Total records returned: 2 admin@(f5-2000-1)(cfg-sync In Sync)(Active)(/Test-2)(tmos)# show net ipsec traffic-selector --------------------------------------------------------- Net::IPSec::Traffic Selector : SRX_1 --------------------------------------------------------- Security Policy Entry Source : 172.17.73.0/24 Destination : 172.31.31.0/24 Direction : out Policy ID : 39906 Tunnel State : up Traffic Packets : 416 Bytes : 41.6K --------------------------------------------------------- Net::IPSec::Traffic Selector : SRX_1 --------------------------------------------------------- Security Policy Entry Source : 172.31.31.0/24 Destination : 172.17.73.0/24 Direction : in Policy ID : 39905 Tunnel State : up Traffic Packets : 507 Bytes : 60.8K
Pinging is successfuI from 172.31.31.200 to 172.17.73.4:
C:\>ping 172.17.73.4
Pinging 172.17.73.4 with 32 bytes of data:
Reply from 172.17.73.4: bytes=32 time=4ms TTL=252
Reply from 172.17.73.4: bytes=32 time=4ms TTL=252
Reply from 172.17.73.4: bytes=32 time=4ms TTL=252
Reply from 172.17.73.4: bytes=32 time=3ms TTL=252
Ping statistics for 172.17.73.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms
Conclusions
F5 BIG-IP does not need any specific IKE/IPsec virtual server configured to be able to terminate IPsec tunnels. Some of the IPsec configuration details are expressed in different style in BIG-IP, like the lifetimes (minutes instead of seconds as is more common) and the DH groups. Nevertheless, the IPsec configurations are quite similar in all devices.
Note: In BIG-IP LTM 11.6.0 there is currently (12-July-2015) a caveat described in SOL16699:
“The Traffic Management Microkernel (TMM) may produce a core file and restart during failover due to invalid memory access in IPsec components.
This issue occurs when all of the following conditions are met:
- Your BIG-IP system has an IPsec tunnel enabled.
- The system is a member of a high-availability pair.
- The system transitions from standby to active.”
In 11.6.0 HF5 this is still unresolved but engineering hotfix is available from F5 support. In 11.5.x the issue has already been fixed in 11.5.3.
This is a nice write-up of an issue I’ve observed elsewhere as well. Thanks!
Great work, thanks for sharing!