Hybrid infrastructure models are nothing new, they just happen to be the reality that most enterprises find themselves in today. Whether it’s compliance/data security that necessitates splitting workloads and/or data, or just a desire to build a public cloud migration path, seamless and secure on-prem <> public cloud network connectivity is frankly table stakes for success.   

Even as a L7 device, one of the things I’ve always admired about the BIG-IP is that it never lost site of integrating a hyper-flexible networking engine for a base to add further functionality to. Pair that engine with IPSec (like the BIG-IP does), and I think you’ll be hard pressed to find requirements that this solution can’t meet. Whether you have specific and/or stringent cryptology requirements, or need multiple/advanced tunnel and routing support, you automatically get that when you configure the BIG-IPs as your IPsec site to site VPN endpoints. And the best news is that customers who’ve deployed F5 solutions in their environment may already have the technology in place to implement secure, resilient, IPsec based hybrid cloud connectivity.

Many customers interested in this design opt to connect their on-premises BIG-IP to a cloud native IPsec endpoint (such as Azure VPN Gateway), and others may choose to use BIG-IPs as both end points. For the BIG-IP to BIG-IP use case, here is a guide to configuring the BIG-IPs.  Hopefully you’ll find it useful, and please let me know through the comments if there is anything that isn’t clear. I’ll keep this as updated as I can.

Below is a graphic of the test environment. For this scenario, BIG-IP v14.1.0.1 was used, and licensed with the Local Traffic Manager (LTM) module.

Each environment has one BIG-IP acting as endpoint (or gateway) for the site to site VPN. That BIG-IP has a publicly routable NAT address that points to a locally bound Self IP (206.124.129.147 <> 10.0.1.137 & 35.182.114.184 <> 10.200.5.13). This guide assumes that you have completed the basic BIG-IP provisioning (deployment, licensing, Self-IPs & routes) already.

 

Configuration Steps (each step is to be done on each BIG-IP)

If an option in the BIG-IP configuration page is not explicitly listed below, assume that the default setting was kept.
I have added screenshots of the configuration below each step for further reference, if needed.

Step 1. Create an “IPsec Policy” on each BIG-IP

The first step in configuring the BIG-IPs to act as IPsec gateways is to create the IPsec Policies. The IPsec Policy sets the configuration for IKE Phase 2, which sets the encryption standards for the data channel.

From the left hand navigation menu, select “Network”, then “IPSec”, then “IPSec Policies”, then select the “Create” button.
For the Name, enter a unique name for this policy (ex. “IPSEC_POLICY1”)
For the IPSec Protocol option, select to use “ESP”, as we want full message authentication plus payload encryption.
For the Mode, select “IPSec Interface”
For the IKE Phase 2 Configuration, select the IPSec settings that match your security requirements. Make sure these settings match what is configured on the IPsec Policy on the remote BIG-IP as well.
For our testing, we selected SHA-1, AES-256, MODP1024, None, 1440, 0
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

Step 2. Create a “Traffic Selector” on each BIG-IP

The second step is to create the Traffic Selectors. A Traffic Selector is a simple source/destination IP matching mechanism used to determine which IPsec tunnel will be used for an specific incoming packet. This is critical when you are using your BIG-IPs for multiple tunnel endpoints.

From the left hand navigation menu, select “Network”, then “IPSec”, then “Traffic Selectors”, then select the “Create” button.
For the Name, enter a name that will describe this specific traffic selector (ex. “SELECTOR_TO_PUBLCOUD” or “SELECTOR_TO_ONPREM”)
For the Source IP Address or CIDR, enter the local network information in CIDR notation (ex. 10.0.1.0/24)
For the Destination IP Address or CIDR, enter the remote network information in CIDR Notation (ex. 10.5.200.0/24)
For the IPsec Policy Name, select the policy created in step 1.
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

*For advanced configurations, you can change the matching order, or the packet matching criteria found in the advanced settings. For our configuration, none of these were changed from the defaults.

Below are minimized screenshots from a working configuration for reference

  

 

Step 3. Create an “IKE Peer” on each BIG-IP

The third step is to configure the IKE Peering. There is a lot of configuration within this step, and it is critical to get this configured correctly in order for the IPsec tunneling to work. The IKE Peer configuration is the information that allows the BIG-IPs to establish enough trust and awareness to start the IPsec negotiation process.

From the left hand navigation menu, select “Network”, then “IPSec”, then “IKE Peers”, then select the “Create” button.
For the Name, enter a unique name that will describe this specific BIG-IP (ex. IKE_PEER_AWS, or IKE_PEER_ONPREM).
For the Remote Address, enter the NAT address of the remote device (ex. 206.124.129.147 or 35.182.114.184)
For the Version, select Version 2. There are significant improvements in V2, including enhancements to reliability and built in NAT-T support.
For the IKE Phase 1 algorithms, select the security algorithms to meet your requirements.
For our testing, we used SHA-256, 3DES, SHA-256, MODP1024, and a lifetime of 1440 minutes. Make sure these settings match what is configured on the IPsec Policy on the remote BIG-IP as well.
For the IKE Phase 1 Credentials, you have the option to use Certificate based or Preshared Keys for authentication. For our testing we used a Preshared Key.
If you select Preshared Key, enter a secure password as a key. Make sure this key matches the key used on the remote BIG-IP.
For the Traffic Selector, select the Traffic Selector created in step 2.
Since both BIG-IPs are behind NATs in this environment, set NAT Traversal to “On”
The next ID Values are used to establish identity. Keep all of these set to Address and Override (for both Presented & Verified).
For the the Presented ID Value, enter the NAT address of the local BIG-IP.
For the Verified ID Value, enter the NAT address of the remote BIG-IP.
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

Step 4. Create the “IPsec Interface Profile” on each BIG-IP

The next step is to create the IPsec Interface Profile in order to attach it to the BIG-IP Tunnel.

From the left hand navigation menu, select “Network”, then “Tunnels”, then “Profiles”, then “IPsec Interface”, then select the “Create” button.
For the Name, enter a unique name that will describe this profile (ex. PROFILE_IPSEC)
For the Traffic Selector, select the Traffic Selector created in step 2 (You may need to enable the “custom” selection).
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

Step 5. Create the “Tunnel” on each BIG-IP

The next step is to create the network Tunnel used for packet traversal on each BIG-IP.

From the left hand navigation menu, select “Network”, then “Tunnels”, then select the “Create” button.
For the Name, select a name that describes this tunnel (ex. “TUNNEL_TO_ONPREM”)
For the Profile, select the IPsec profile created in step 2
For the Local Address, enter the actual IP of the local BIG-IP (Not the NAT IP)
For the Remote Address, enter the NAT IP of the remote BIG-IP
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

Step 6. Create the Self-IPs for the Tunnel

The next step is to bind a self IP on each side of the Tunnel. These IPs are encapsulated within the tunnel, and are used for endpoint determination, not actual routing. For this reason, we are able to use “fictional” IPs/networks. Just be sure to select a netmask that encompasses the IPs into a single network.  

From the left hand navigation menu, select “Network”, then “Self IPs”, then select the “Create” button.
For the Name, select a name that describes this Self-IP (ex. “SELF_IPSEC1”).
For the IP Address, select the IP address you have chosen
For the Netmask, select the Netmask for the CIDR
For the VLAN / Tunnel, select the Tunnel created in step 5.
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

Step 7. Create the Routes on the BIG-IPs

This step will ensure that BIG-IP is aware of the remote networks and which Tunnel to use (if any) to send packets through to reach their destination.

From the left hand navigation menu, select “Network”, then “Routes”, then select the “Add” button.
For the Name, select a name that describes this route (ex. “ROUTE_TO_PUBCLOUD, ROUTE_TO_ONPREM”)
For the Destination, enter the remote network
For the Netmask, enter the netmask of the remote network
For the Resource, select “Use VLAN /Tunnel”
For VLAN / Tunnel, select the Tunnel created in step 4.
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

Step 8. Create the Forwarding Virtual Servers

With the Forwarding Virtual Server, the BIG-IP will accept & forward packets sent to it and with the configuration above, direct them through the Tunnel. Without the Forwarding Virtual Server, the packets would be dropped at the BIG-IP.

In our use case, we chose to use wildcards for our Forwarding Virtual Servers for simplicity, however you can tighten them down to match local and remote networks if you wish.

From the left hand navigation menu, select “Local Traffic”, then “Virtual Servers”, then select the “Create” button.
For the Name, enter a name that describes this Virtual Server (ex. “VS_IPSEC_FORWARDING”)
For the Type, set it to “Forwarding (IP)”
For Destination Address/Mask, enter “0.0.0.0/0”
For Service Port, enter “0”
In the Basic section
Change the Protocol to “* All Protocols”
Then click the “Finished” button. Be sure to complete this step on both BIG-IPs!

Below are minimized screenshots from a working configuration for reference

  

 

That’s it! Now the site-to-site IPsec tunneling between the BIG-IPs should work. If the local routes are set up correctly, clients in one environment should be able to communicate with workloads in the other.

 

 

 

A couple of notes:

You’ll need to make sure routing on your local networks is set up correctly. This means setting up the default & local routes for the BIG-IP and client/servers.

The correct security/firewall rules need to be created to allow IPsec traffic through to your BIG-IP. For Azure / AWS / GCP, this means changes to your security groups to allow IPsec.

If you’re interested in using an iAPP to configure IPsec tunneling between BIG-IPs (vs. the manual configuration in this article), my colleague Greg Coward wrote an excellent one up. Check it out here.

I’d love to continue this blog series on IPsec tunneling with BIG-IP. If you can think up a good topic, please post it in the comments below.

Thank you! - Ryan