Step 2: Configure and Verify an IPsec VPN
It has been a big day, we know. Before you go home, there’s one more ask for the new branch office. You'll need to establish a secure IPsec VPN tunnel to the remote corporate office. This tunnel allows members of the trust zone to securely reach specific corporate resources on the 172.16.200.0/24 subnet over the Internet.
Secure tunnels are a key feature of SRX platforms. Being able to send sensitive traffic over the public Internet without concern for eavesdropping, or data theft, is no small task. An IPsec VPN lets you securely tunnel traffic through the public Internet. Because the traffic is tunneled, there's no need to perform source NAT.
Don't worry, we'll make this easy for you!
This step covers how to:
- Configure st0 tunnel interfaces
- Configure static routing to steer traffic into the IPsec tunnel
- Configure IKE and IPsec parameters for a dynamic route-based VPN
- Adjust security policies to ensure that only traffic from the trust zone sent to 172.16.200.0/24 is presented to the IPsec tunnel
- Use the Junos CLI to verify IPsec VPN operation
IPsec VPN Overview
In this example, traffic sent from the trust zone to 172.16.200.0/24 uses the IPsec tunnel. This traffic bypasses source NAT and exits the remote end with the original source IP from the 192.168.2.0/24 trust-vlan subnet.
The tunnel operates point-to-point between the branch and the remote office. This makes IP address assignment optional. In this example, we assign addresses to the tunnel endpoints to permit ping testing as a diagnostic aid. A static route is used at each end to direct traffic into the tunnel. Note that the static route at the remote location matches the 192.168.2.0/24 subnet of the trust zone. You must match on this address because source NAT does not occur for traffic using the tunnel.
The topology shows a cloud between the branch and remote location. Typically this cloud is the Internet. To reduce the number of devices in our topology, we have a direct connection between the branch and remote locations. As a result, we have a single 172.16.1.0/24 subnet that spans the Internet cloud.
This means that later, when you define the Internet Key Exchange (IKE) local and remote gateways, the two endpoints share the 172.16.1.0/24 subnet. There's no difference in configuration or operation if the IKE gateways are on remote subnets. Specifying a remote IKE gateway is the typical use case when the two sites have intervening hops through the Internet.