A quick and dirty gateway through OpenVPN
Suppose our Linux box has an existing OpenVPN tunnel to a remote LAN. We want this machine to act as a gateway, sending traffic from one of its interfaces across that OpenVPN tunnel.
The need is short-term, so we don’t care about persisting the setup over reboots, and we’ll be a little devil-may-care with firewalling.
We plug a switch into a USB NIC for our new, short-term local LAN.
Linux calls the NIC enx8cae4ce94ec2.
Set up the network interface with a new address on a new subnet (192.168.222.0/24) for our short-term local LAN:
🐚 ~ $ ip addr show enx8cae4ce94ec2
16: enx8cae4ce94ec2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 8c:ae:4c:e9:4e:c2 brd ff:ff:ff:ff:ff:ff
inet6 fe80::2e40:5f30:7d9b:db20/64 scope link noprefixroute
valid_lft forever preferred_lft forever
🐚 ~ $ sudo ip addr add 192.168.222.1/24 dev enx8cae4ce94ec2
Run dnsmasq on that interface to provide DHCP.
We don’t care about providing DNS by dnsmasq, since we want these short-term clients to use DNS servers on the remote LAN (i.e., 10.0.0.2 and 10.0.0.3).
Here’s the minimal dnsmasq.conf:
interface=enx8cae4ce94ec2
domain=example.com
dhcp-option=6,10.0.0.2,10.0.0.3
dhcp-range=192.168.222.50,192.168.222.150,255.255.255.0,12h
port=0
domain-needed
bogus-priv
strict-order
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
Check the syntax of our config file, then fire up dnsmasq:
🐚 ~ $ /usr/sbin/dnsmasq -C ./dnsmasq.conf --test
dnsmasq: syntax check OK.
🐚 ~ $ sudo /usr/sbin/dnsmasq -C ./dnsmasq.conf
Because this temporary setup lives in a fairly trusted environment, we won’t worry about firewalling things:
🐚 ~ $ sudo sysctl -w net.ipv4.ip_forward=1
🐚 ~ $ sudo iptables --policy FORWARD ACCEPT
🐚 ~ $ sudo iptables -A INPUT -i enx8cae4ce94ec2 -j ACCEPT
Make sure our OpenVPN is up as tun0, then:
🐚 ~ $ sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
🐚 ~ $ sudo iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
(br0 is the “outside”/main interface of our gateway, through which traffic not bound for example.com/OpenVPN will flow.)
That does it.
Devices hanging off the switch attached to enx8cae4ce94ec2 should be able to hit things on the other side of tun0.
If this was a long-term setup, we’d carefully firewall the new LAN and make sure our process supervisor/init manages the dnsmasq server.
#linux