How to set up NAT in windows server 2008 r2 for IPSec tunnel use

Question

I am having troubles setting up the whole IPSec tunnel thing.

What i have:
1. Router that only has a VPN/IPsec passthrough functionality (IP 192.168.0.1)
2. Windows Server 2008 R2 which has group policies set up for the IPSec tunnel. (Servers IP 192.168.0.2; gw 192.168.0.1)
3. Linux machine has an application (IP 192.168.0.3; gw 192.168.0.2)

The other end of the IPSec tunnel is at another location through the internet.

The company on the other end of tunnel told me, i must have IP 10.100.101.102 as a source ip for all my packets coming into IPSec tunnel from the Linux machine.

So the idea is:
1. Linux forms a packet and sends to the destination PC (111.222.333.444) on a specific port. So src=192.168.0.3; dst=111.222.333.444
2. The packet travels to Windows server.
3. Server takes the packet and changes the src to src=10.100.101.102 leaving the dst the same.
4. Server encrypts the packet using the IPSec options and sends it to the remote endpoint throught the router.
5. [actions at the remote endpoint]
6. Windows server receives the response and decrypts it.
7. Changes the dst (10.100.101.102) to the local dst=192.168.0.3.
8. Send the packet to the Linux and the application.

How do i achieve all this? I fail to understand how NAT is working on windows server. I configured it at 'routing and remote access' but i didnt see any options of specifying which source IP and Port having packets should be altered to have the 10.100.101.102 as src.

Answer 1

you'd need definite answers to the following questions before you can proceed:

1. can you ping the router from the linux box?

2. if you can, can you traceroute from the linux box to the router? from the above questions, I want to make sure that a. your traffic goes to the windows box indeed and then the router, not directly to the router. the tracert will tell you that for sure. b. your internal routing infrastructure is working right.

3. what is the other company's IPsec device's IP address? IPsec tunnels are quite static and you cannot configure them using DNS names or so, so you must know the address of the IPsec remote end point.

4. does the other endpoint support IPsec Nat-Traverse (NAT-T) ? if they cannot tell you this for sure, ask them the make and model of that endpoint device and if possible , the software/firmware version of that and search for such info.

from what you're telling us above, it seems that first you have to get your internal routing right, as the router will send the traffic directly to the Linux and gets it from it as well, without even letting the windows into the game;unless you either manually mess with routing tables on all 3 boxes, ALL 3(well, maybe not the windows if you've setup RRAS on it but Even that needs checking), or use different subnets for different seagments; for example 192.168.0.1 for router, 192.168.0.2 for windows,another IP like 192.168.1.1 for windows and 192.168.1.3 for linux. By the way if you go with this second approach, make sure that the router knows about the second subnet as well by putting a route to the 192.168.1.x network via the 192.168.0.2 (the windows IP in the same range as the router's IP).

after you got all the c..p above right, now you can start working with the real thing! this is what happens:

we name the IP on the linux LinIP

we name the IP of the windows on the Linux Seagment WinIPL

we name the IP of the windows on the router seagment WinIPR (in case you've chosen manual routing table manipulation approach above, the two WinIPs will be the same)

we name the IP of the router on your internal side RoutIPint

we name the IP of your router on the public facing side (the IP that ISP gives you) RoutIPext.

we name the remote IPsec end point IP, RemTunIP.

we name the IP of the resource you're trying to reach at the other company behind the Tunnel RemResIP.

when your linux generates a packet , it puts LinIP as the source, and RemResIP as the dest; gives that to the Windows Box through the IP WinIPL.

Windows Box, if setup right, will put that packet (including the IP header mentioned above) into another packet, puts WinIPR as the source, RemTunIP as the dest, DIGITALLY SIGNS WinIPR and RemTunIP and gives it to the router

the router NATs that signed packet's to RoutIPext and RemTunIP. here is one of the many places where this chain can get messed up as the SIGNATURE is here violated and the packet gets invalidated UNLESS your windows box and the other Company's IPsec end point are NAT-aware; aka have NAT-T enabled on them. use this kb article from microsoft to enable Nat-T on your windows box(it might seem that it is for VPN at the first sight, but it is a general IPsec settings so DOES do the job): http://support.microsoft.com/kb/926179 if your remote company's IPsec device is behind the NAT as well, put 2; if not or if the other company does not support Nat-T(which implies that they're not NATting their IPsec traffic indeed),put 1.

when the remote edge Ipsec device got your packet (FINALLY!), it would be in the form of RoutIPext and RemTunIP . using Nat-T it will extract the packet with WinIPR and RemTunIP, using IPsec Decryption it will extract the packet with LinIP and RemResIP, routes it accordingly and hands it over to the resource your linux was trying to reach.

so you need to have:

a. remote office made aware of your local linux subnet

b. set the policy of IPsec on your windows to form the tunnel with WinIPR and RemTunIP not anything else.

c. have the matching policy of RemTunIP and WinIPR setup at the remote site.

d. have the passthrough enabled on your router.

e. have passed the pre-reqs as I told before the IPsec part above(tracert and subnetting and stuff)

!!!SO IT IS NOT TRIVIAL AT ALL!!!