BIG-IP to Azure Dynamic IPsec Tunneling
In one of my previous posts we took a look at configuring the BIG-IP to act as a site-to-site VPN tunnel endpoint for connecting on-premises environments with Azure. At the time the BIG-IP only supported policy-based, (static-route) VPN tunnels. Now, with the latest release of the F5 BIGIP OS, (version 12.x), both dynamic as well as static-based IPSec VPNs are supported. “But Greg, why do I care?”, you may ask. Excellent question!
For a good primer on the two version of IPSec VPNs checkout this blog post from Russ Slaten. From a practical standpoint, if your organization needs to connect multiple endpoints, (including Multi-Site, Point-to-Site, and VNet-to-VNet ), to their Azure environment, you must utilize a dynamic route-based VPN configuration. So with that said, let’s take a look at a typical configuration setup.
Note: The following steps assume the BIG-IP has been initially configured settings including, but not limited to, licensing, provisioning, and network configurations. Addtionally, an iApp template is available here. The iApp will facilitate the deployment described below.
Setup – Configure each of the following objects in BIG-IP as illustrated below.
Step 1. Create IPsec Policy – The following IPsec policy created utilizes SHA-1’ for authentication, ‘AES-256’ for encryption, and Diffie-Hellman (MODP1024) Perfect Forward Secrecy. However, you have various options with regards to levels and types of auth/encryption. Refer to the Azure’s page for requirements.
Step 2. Create Azure Traffic Selector – During the initial tunnel negotiation, the Azure VPN gateway will advertise ‘0.0.0.0/0’ for both source and destination subnets regardless of the actual on-premises and Azure VNet address spaces. The BIG-IP traffic selector should match this to allow for Azure initiated tunnels. The actual traffic direction, (routing) will be determined by the static route entries, (see Step 6 below).
Step 3. Create Azure Peer – The Azure IKE peer utilizes IKE v2, ‘SHA-1’ for authentication, ‘AES-256’ for encryption, Diffie-Hellman (MODP1024) Perfect Forward Secrecy, and a ‘preshared key’.
Step 4. Create IPsec tunnel profile and tunnel – This is where dynamic, (aka route-based) IPsec and policy-based IPsec diverge. Utilizing an IPsec tunnel interface allows us to create static routes with the tunnel endpoint as the next hop. This way any traffic destined for the Azure side will be routed through the tunnel. By contrast, policy-based VPNs require a policy that explicitly states which traffic can use the VPN.
Step 5. Create Tunnel Endpoint Self-IP and IPsec interface Self-IP. Note:Although required, the address assigned is not utilized by Azure tunnel and the only requirement is the subnet must be unique.
Step 6. Create Route – A static route with the newly created tunnel as the next hop allows any traffic hitting the BIG-IP and destined for the specified subnet to be routed through the IPsec tunnel.
Step 7. Create a forwarding virtual server – The simple forwarding virtual server listens for and directs traffic over the IPsec tunnel.
Additional Links:
CodeShare - IPSec Tunnel Endpoint iApp Download
Connecting to Windows Azure with the BIG-IP
About VPN devices for site-to-site virtual network connections
Configuring IPsec between a BIG-IP system and a third-party device
Windows Azure Virtual Networks
Static vs Dynamic Routing Gateways in Azure – Russ Slaten Blog Post
Published Dec 17, 2015
Version 1.0
Greg_Coward
Employee
EmployeeGreg_CowardEmployee
Employee
BhavinNimbostratus
In step 1, the PFS needs to be set to none to match Azure default settings. Otherwise the Phase 2 tunnel doesn't renew after it reaches its lifetime. I've been fighting this the past few days and with F5 support discovered that is the setting that's needed.
You can have multiple tunnels on the same float IP or self IP.
a_basharatCan we on the forwarding virtual server, instead of using a wildcard network address such as 0.0.0.0/0, use an IP Address like A.B.C.D/24 and use that as the termination of the tunnel at the F5? I am just concerned of a wildcard IP Address on the VS open to all
If we need a second IPSec Tunnel, what will the F5 end if the Self IP has been taken already by the first IPSec tunnel?
Per Reddy's question, in this specific example the IP address "10.23.54.2" is more of a placeholder IP because without some kind of IP on the tunnel interface you cannot add a route using that tunnel interface. The IP doesn't play any part in subsequent traffic-selector decisions.
"We do not have Public IP segment on the F5" - That's normal of course for cloud deployments. That's why NAT-D (NAT detection) needs to be enabled for IKEv1 tunnels (it's native to IKEv2). Both peers have to have this enabled. You may wish to forward traffic inbound to the cloud bearing UDP destination ports 500 and 4500 to the (10.x.x.x) self IP configured on the VLAN (not tunnel interface).
Per Ricardo Raza's question: You must use a cloud routeable private IP on the VLAN. The correct IP depends on the network(s) you're using inside your cloud environment.
Ricardo_Raza_14Hi Which IP do you need to put in the self IP associated with the VLAN?
Reddy1Altostratus
Even i have the Local Tunnel End point configured with the Private IP (We do not have Public IP segment on the F5). I have built the IP 10.0.0.1 on the F5 and had it X'd on the Firewall to a public IP. I am curious to understand why it doesnt work Public IP on the F5 Vs X'd.
Thanks for your time !!
- Reddy1
Thanks for the detailed procedure document Greg!!! I have a question with the Self-IP, May i know why we need the self-IP (10.23.54.2) ? Does the IP has any significance ? If the remote-IP is 11.12.13.14 , Do i need to create a self IP something like 11.12.13.15 and assign it to the tunnel?
MaaS_170765Thanks Greg. If that is the case, do you know how Azure can support a Windows RRAS behind a NAT server to be the IPSec client on the customer network? That's what I had set up before trying to use the LTM instead, which I would prefer over a Windows machine anyday. Do you know if there's something different about the VPN connection when the endpoint is Windows RRAS? Does the publicly-routable IP requirement only apply to policy-based and not route-based connections? I'll upgrade to v12 in any case, but if I could use the LTM behind my FW as a Azure VPN client, that would be great.- Greg_CowardHi, Unfortunately, there is an Azure requirement that the IPsec endpoint must be a publicly routable IP that is not behind a NAT device. I've done testing as well to verify this limitation. Sorry MaaS
- MaaS_170765Hi Greg, thanks for your great post. Does the IP address assigned to the LTM have to be publicly routable, or can it be a private IP that is behind a NAT device? I also read your previous post on policy-based IPsec VPNs using the LTM to connect to Azure, but I am limited in that my LTM is behind a NAT (and currently running version 11.6 for that matter, so I believe I'm limited to policy-based VPN until I upgrade to 12.x). Is there a way to use NAT Traversal and configure a LTM that is behind a NAT to create an IPsec VPN with Azure?
