Changes between Version 3 and Version 4 of NatHack

Timestamp:

01/28/11 06:40:23 (13 years ago)

Author:

krzee king

Comment:

small change

NatHack

@@ -13 +13 @@
 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. 
+If you could you should definitely add routes to the gateway, telling it to send the packets for the VPN to the openVPN server. Or at least add that route to the 10.10.2.20 machine. 
 
-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.
+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, but might also be your only solution.
 
 == openVPN server on Linux ==