Mastering IPSec Tunnels: Policy-Based Mode & DNAT Configuration on T1 Routers

This blog post dives into setting up an IPSec tunnel in policy-based mode and configuring Destination Network Address Translation (DNAT) on a T1 router. Many companies leverage IPSec alongside NAT for various reasons, such as addressing issues with overlapping subnets or enhancing security measures.

The article will guide readers through the process of establishing an IPSec tunnel in policy mode on NSX and configuring both source and destination NAT. This guidance is particularly relevant when IPSec is active in policy mode.

Prerequisites – what you need

The following items are required to use the tutorial:

• VMware NSX version 4.0.0.1 or a newer version. 
• A solid understanding of IPSec.
• Similarly, fundamental knowledge of NAT.

Short overview: the network diagram

The network diagram is shown here for a better overview.

The Scenario: set up an IPSec tunnel between a T1 router and a Sophos XGS

In this scenario, we’re trying to set up an IPSec tunnel between a T1 router and a Sophos XGS. We need to translate the subnet (192.168.234.0/24) behind the T1 router to 192.168.111.0/24. This means that the Sophos Firewall only sees the subnet 192.168.111.0/24 and not 192.168.234.0/24.

Setting up the VPN tunnel on NSX

Tier-1 Gateways

t1_vpn_server > Edit > Route Advertisement > All IPSec Local Endpoints > enable

t1_vpn_server > Edit > Route Advertisement > All Connected Segments & Service Ports > enable

VPN

Here is a step-by-step guide on how to set up the VPN. The most important elements that you need to consider are circled in red on the screenshots.

Step 1: create a VPN Service

Step 2: create a Local Endpoints

Step 3: create IKE Progfile

Step 4: create IPSec Profile

Step 5: create IPSec session

We’ve finished setting up the VPN on the NSX side.

Just a heads-up: the settings on the partner side aren’t covered in this article. Once both sides are set up correctly, we can activate the tunnel.

What’s the next step?

To make sure the local network (192.168.234.0/24) can access the remote network (172.16.16.0/24), we need to set up a source NAT configuration on the t1vpnserver. This will make the remote network (172.16.16.0/24) accessible from the original subnet.

To do this, they just follow a few simple steps:

Once Source NAT was set up, VM1 was able to successfully ping Server1.

Just to flag up that VM1 still can’t reach the srv1 and srv2 networks because there’s no DNAT configured yet. When you’re setting up DNAT, it’s important to remember that the NAT rule should be created according to the diagram. It’s important to make sure that when you’re setting up the DNAT rules, you set ‘Apply to Policy Based VPN’ to ‘match’. Otherwise, the NAT rule won’t do anything.

Destination Nat configuration:

Just a heads-up: if you’re using IPSec in Route-Based mode, you don’t need to set “Apply to Policy-Based VPN” to “Match” because, in Route-Based IPSec, all the packets you’ll be translating (NATing) are applied to your VTI (Virtual Tunnel Interface). With route-based IPSec VPN, you can set up tunnels for traffic based on either static or dynamic routes.

The setup of IPSec in Route-Based mode is pretty similar to that in Policy-Based mode. We’ll save further discussion on this for another article.

VM1 can now ping or access srv1 or srv2 via RDP.

That’s it already!

In this article, we have taken you through the steps to set up an IPSec tunnel in policy mode on NSX. From setting up VPN services to configuring DNAT rules, we’ve covered the basics to ensure secure and efficient network communication. We wish you every success in implementing this measure yourself.

Ready for a deep dive?

Are you interested? Here are a few articles that you can use to read more about the topic.

• Add an NSX IPSec VPN Service
• VMware NSX 4.0.0.1 Release Notes