Changes between Initial Version and Version 1 of NatHack

Timestamp:

01/28/11 00:11:28 (13 years ago)

Author:

arnotixe

Comment:

created nat-hack page

NatHack

@@ +1 @@
+= NAT-hack =
+
+First of all: NAT is bad; you should definately try to ROUTE your networks, not NAT them. That's why this page's title is nat-HACK.
+
+When you connect different networks you should plan ahead so that all the computers can talk together with ROUTING. But sometimes you just can't change the routing in your network: Unwilling computer department, no password to the router, etc etc.
+
+'''What does the NAT-hack do? Can I use it as a universal problem solver?'''
+The NAT-hack is a way of making your openVPN server rewrite ALL TRAFFIC coming in from its VPN tunnels, sending it on to its destination but FAKING that the openVPN server is the SOURCE. This way all machines that the openVPN server is able to communicate with, can also be reached from the VPN tunnels. 
+
+It's more or less like everyone in the neighborhood using your phone. You would get a lot of work coordinating what calls are for what neighbor. But it could work. Would be better if everyone got their own phone, so the calls could be routed directly.
+
+So the NAT-hack is '''NOT a problem-solver''', more a problem-creator. But it could get you out of this following tricky situation: (See [http://www.secure-computing.net/wiki/index.php/Graph] for an image)
+You have an openVPN server obviously sitting on a network (LAN). Now you want your machines from your VPN to be able to reach some machine on the LAN. Now, the client 10.8.0.6 on your VPN tries to contact 10.10.2.20. That's OK, the openVPN server forwards the packet to 10.10.2.20. But 10.10.2.20 doesn't know where the 10.8.0.6 machine is supposed to be. So it sends it to the gateway. Now, the gateway doesn't know either, so it sends it to the internet. The internet just ignores it without warning, because 10.<something> addresses aren't allowed on the internet.
+
+If you could you should definitely add routes to the 10.10.2.20 machine, telling it to send the packets for the VPN to the openVPN server. Or at least add that route to the gateway. 
+
+But what if you don't have access to the 10.10.2.20? Nor the gateway? Then you will need the NAT-hack, so that the openVPN server forwards all packets it receives from the VPN, saying "these packets are all from me". And take care of returning the answer packets to the correct destination. All traffic from the VPN will appear to come from the openVPN server. Might not be good, might also be your only solution.
+
+== openVPN server on Linux ==
+<coming up maybe>
+== openVPN server on Windows ==
+Here [http://openvpn.net/archive/openvpn-users/2006-09/msg00031.html] you've got a nice howto on how to do real NAT with windows xp. Not the NAT that messes up your LAN settings, but real NAT without touching your IP address setup.
+
+On my openVPN server, though, the internet link was on one card, and the other links on another card. 
+eth0 internet  = my internet connection, 10.0.0.x
+eth1 corporate = my company's connection, 172.31.25.x
+vpn0 openvpn   = the openvpn network "card", 10.8.0.x
+
+As '''I wanted to connect the VPN clients to the corporate network''' I had to '''add both the internet NIC and the corporate NIC as FULL''':
+
+1) Modify Registry Entry:
+HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
+IPEnableRouter=1
+
+2) net stop remoteaccess // Stop the RAS Service
+3) netsh routing ip nat install
+4) netsh routing ip nat add interface "eth0 internet" full
+4.5) netsh routing ip nat add interface "eth1 corporate" full
+5) netsh routing ip nat add interface "vpn0 openvpn" private
+6) netsh routing ip nat add interface Internal private
+
+(Actually I had to first open Control Panel | Administrative Tools | Services, find Remote Access Connection Manager and ENABLE it before the step #7)
+
+7) net start remoteaccess
+
+'''Check it''' with
+
+netsh routing ip nat show interface
+
+should look something like:
+
+{{{
+NAT Internal Configuration
+---------------------------
+Mode              : Private Interface
+
+NAT eth0 internet Configuration
+---------------------------
+Mode              : Address and Port Translation
+
+NAT eth1 corporate Configuration
+---------------------------
+Mode              : Address and Port Translation
+
+NAT vpn0 openvpn Configuration
+---------------------------
+Mode              : Private Interface
+}}}
+
+
+
+And of course, the classic windows apply method: Reboot the machine for the settings to take effect.
+
+NOTE that the NAT-hack does '''not free you from setting up routes to the networks''' neither on the client nor on the server.
+
+== To set up a route on the clients ==
+=== Windows client ===
+route add 172.31.25.0 mask 255.255.255.0 10.8.0.1      (this will tell the client that there's a 172.31.25.x network behind the openvpn server at 10.8.0.1)
+route add 32.8.8.0 mask 255.255.255.0 10.8.0.1         (this will tell the client that there's another network too, 32.8.8.something, behind the openvpn server at 10.8.0.1)
+You can keep adding more routes till you reach everything you need.
+
+=== Linux client ===
+route add -net 172.31.25.0/24 dev tun0     (or whatever the vpn tunnel is called)
+
+
+