In this scenario, a large insurance company wants to establish a VPN between a gateway in Chicago and a host in Minneapolis when both networks are behind a firewall.
Situation
Suppose you are a large home owner’s insurance company based in Minneapolis and you just opened a new branch in Chicago. Your Chicago branch needs to access the customer database from the Minneapolis headquarters. You want to make sure the information being transferred is secure because the database contains confidential information about your customers such as, names, addresses, and phone numbers. You decide to connect both branches over the internet using a Virtual Private Network (VPN). Both branches are behind a firewall and are using Network Address Translation (NAT) to hide their unregistered private IP addresses behind a set of registered IP addresses. However, VPN connections have some well known incompatibilities with NAT. A VPN connection discards packets sent through a NAT device because NAT changes the IP address in the packet, thereby invalidating the packet. However, you can still use a VPN connection with NAT if you implement UDP encapsulation.
In this scenario, the private IP address from the Chicago network is put in a new IP header and gets translated when it goes through Firewall-C (see following image). Then, when the packet reaches the Firewall-D, it will translate the destination IP address to the IP address of System-E, therefore the packet will be forwarded to System-E. Finally, when the packet reaches System-E it strips off the UDP header, leaving the original IPSec packet, which will now pass all validations and allow a secure VPN connection.
Objectives
In this scenario, a large insurance company wants to establish a VPN between a gateway in Chicago (Client) and a host in Minneapolis (Server) when both networks are behind a firewall.
The objectives of this scenario are as follows:
- The Chicago branch gateway always initiates the connection to the Minneapolis host.
- The VPN must protect all data traffic between the Chicago gateway and the Minneapolis host.
- Allow all users in the Chicago gateway to access an iSeries™ database located in the Minneapolis network over a VPN connection.
Details
The following figure illustrates the network characteristics for this scenario:
Chicago Network - Client
- iSeries Gateway-B runs oni5/OS™ Version 5 Release 4 (V5R4)
- Gateway-B connects to the internet with IP address 214.72.189.35 and is the connection end point of the VPN tunnel. Gateway-B performs IKE negotiations and applies UDP encapsulation to outgoing IP datagrams.
- Gateway-B and PC-A is in subnet 10.8.11.0 with mask 255.255.255.0
- PC-A is the source and destination for data that flows through the VPN connection, therefore it is the data endpoint of the VPN tunnel.
- Only Gateway-B can initiate the connection with System-E.
- Firewall-C has a Masq NAT rule with the public IP address of 129.42.105.17 that hides the IP address of Gateway-B
Minneapolis Network - Server
- iSeries System-E runs on i5/OS Version 5 Release 4 (V5R4)
- System-E has an IP address of 56.172.1.1.
- System-E is the responder for this scenario.
- Firewall-D has and IP address of 146.210.18.51.
- Firewall-D has a Static NAT rule that maps the public IP (146.210.18.15) to the private IP of System-E (56.172.1.1). Therefore, from the clients perspective the IP address of System-E is the public IP address (146.210.18.51) of Firewall-D.
