Static IP for machine on home LAN through OpenVPN and Linode
1 - Get additional IP address for current Linode
2 - Have machine B, behind domestic modem/router connected to Linode by OpenVPN, address would be something like 10.4.10.*
3 - Set up B as if it were a linode exposed to the bad old world - so appropriate firewall etc. Carefully make sure that traffic from the VPN can't access the local LAN.
4 - Tell Linode (A) that all traffic to the 2nd IP address should go straight to B, via the VPN. And that all traffic from B to the internet should externally look like it came from the 2nd IP address. There would be no filtering of traffic at this point. (I think all of this step is handled by iptables.)
The end result is that the new IP address looks and behaves like a Linode but is in fact machine B, still behind my home router.
I know how to do steps 1, 2 and 3, but don't know what's involved in step 4, or even what this is called. Is this NAT? Is this masquerading?
I use shorewall to control iptables on the linode, but I can probably translate iptables rules easily enough.
Thanks for any pointers.
Also please tell me if this is in any way illegal or dodgy (I won't be using it for any dodgy purpose, but the idea of masquerading sounds dishonest to me).
6 Replies
@Shorewall online docs:
One-to-one NAT
If you wanted to use one-to-one NAT to link eth0:0 with local address 192.168.1.3, you would have the following in /etc/shorewall/nat:
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 206.124.146.178 eth0 192.168.1.3 no no
And more documentation is(with lots of warnings and complications). here
The only problem is that the end machine on the vpn doesn't know the way back to the outside world through the vpn server machine, the default route is through eth0, not tun0. So it will need to be told somehow. Either iptables (or shorewall), or route??
At the moment, if you ping the new IP address from the outside world, you see this at the destination (on the vpn interface - tun0):
# tcpdump -nei tun0 icmp
... <blah blah=""> ...
23:46:05.123458 In ethertype IPv4 (0x0800), length 100: [my.home.ip.address] > 10.4.10.21: ICMP echo request, id 9524, seq 1, length 64</blah>
and the reply goes out via eth0:
# tcpdump -nei eth0 dst 84.13.116.69
... <blah blah=""> ...
23:45:25.898551 00:0f:ea:ac:9c:af > 00:08:5c:c2:43:f3, ethertype IPv4 (0x0800), length 98: 10.4.10.21 > [my.home.ip.address]: ICMP echo reply, id 57395, seq 1, length 64</blah>
This would probably solved by routing all traffic through the vpn, but that's not what I want. So now I have to figure out how to make replies to traffic that came in via the vpn, go back out the same way, regardless of the destination address.
Anyone?
@weave:
I know it seems like you are talking to yourself – maybe you are -- but I'm wanting to do something similar someday soon here so I'm watching this thread and appreciate your updates. Thanks for listening.
The best I've been able to achieve so far is to create a default route through the vpn, so all non-local traffic goes that way. If this is done using openvpn, then it is only in effect when the vpn is up, so you will always have access to the internet. So in /etc/openvpn/server.conf (on the vpn server), I put this:
push "route 0.0.0.0 0.0.0.0"
This is not ideal because:
it affects all clients
it affects all traffic, and I only want traffic that is originated through the vpn to go that way.
I'm sure there is a solution using iptables (shorewall for me), but I haven't taken the time to research it.
If someone could give us some keywords, then I'm sure we could find the answer quite quickly.
make the changes to the shorewall nat file (on the linode), as in the example above
add an entry in shorewall rules to allow all traffic from net to the specific INTERNAL machine (or you could restrict this to a few ports, but then you may as well just use dnat)
add a default route on the INTERNAL machine so that traffic goes back through the vpn
you also need to run a firewall on the INTERNAL machine, because you've just blown a huge hole in the one on the linode
Well, that was fun.