[lug] Followup on linking home network to tethered laptop question

[Bear Giles]

Heh, I definitely should have double-checked the command instead of going
from memory. For the VPN it would be


   - iptables -t nat -A POSTROUTING ! -s 192.168.1.0/
   <http://192.168.1.10/32>24 -d 172.31.0.0/16 -o tun0 -j MASQUERADE

and there is no 'DENY' or 'DROP' on NAT routing. There's no need for it if
you're simply limiting by source CIDR, and if you want something more fancy
you need to create the filter in either the existing tables or a new one.

Adding the source restriction doesn't help a lot since my home router will
give an ip address to anyone who asks but it could be limited to specific
addresses that are statically allocated, or to a private CIDR range that
only has a handful of static addresses on it.

Bear

On Wed, Nov 25, 2020 at 4:10 PM Bear Giles <bgiles at coyotesong.com> wrote:

> I have a followup on an old question on linking your home network to a
> tethered laptop (or to a corporate VPN).
>
> On the tethered machine
>
>    - sysctl net.ipv4.conf.all.forwarding=1
>    - iptables -P FORWARD ACCEPT
>    - iptables -t nat -A POSTROUTING ! -d 0.0.0.0/0 -o wlan0 -j MASQUERADE
>
> where 'wlan0' is your wifi network device. You can find the list of
> network devices with either 'ip a' or 'ip route'. You could also specify
> 'ipv6'.
>
> On the client machines
>
>    - ip route add default via 192.168.1.100 dev eth0
>
> where '192.168.1.100' is the tethered machine and 'eth0' is your network
> device.
>
> *To reverse this*
>
> On the client machines
>
>    - ip route del default
>
> On the tethered machine
>
>    - iptables -t nat -L -v -n --linenumbers
>    - iptables -t nat -D POSTROUTING 4
>    - iptables -P FORWARD DROP   -- optional
>    - sysctl net.ipv4.conf.all.forwarding=0  -- optional
>
> where '4' is the line number that contains the rule for network forwarding
> to the tethered device.
>
> *For VPNs*
>
> For VPNS you can change the rules on the client system to
>
>    - ip route add 172.31.0.0/16 via 192.168.1.100 dev eth0
>
> so *only* traffic to that address is routed through the VPN. You would
> delete the route with 'ip route del 172.31.0.0'. (I can't remember if you
> need specify additional values.)r
>
> In addition if you want slightly tighter security you can add this(-ish)
> to the VPN gateway:
>
>    - iptables -t nat -A POSTROUTING ! -s 192.168.1.10/32 -o tun0 ACCEPT
>    - iptables -t nat -A POSTROUTING ! -s 0.0.0.0/0 -o tun0 DENY
>
> where '192.168.1.10' is the IP address of the single system you want to
> grant access to and 'tun0' is the name of the VPN virtual network device.
> I'm not 100% certain since I haven't actually enabled this yet.
>
> */etc/netplan*
>
> If you're using a VPN - so you know you won't be accessing these systems
> except through the VPN - you can add stanzas to your file(s) in /etc/netplan
>
> # Let NetworkManager manage all devices on this system
> network:
>    version: 2
>    renderer: NetworkManager
>    ethernets:
>        eth0:
>            routes:
>               - to: 0.0.0.0/0
>                 via: 192.168.1.1
>                 metric: 100
>               - to: 172.31.0.0/16
>                 via: 192.168.1.100
>                 metric: 10
>               - to: 38.27.45.190
>                 via: 192.168.1.100
>                 metric: 11
>
>
> This shows the default address, a network range, and a specific system
> outside of the network range. I don't think you actually need the 'metric'
> lines - I added them to ensure the priority but the normal rules of "most
> specific match first" should normally work.
>
> Once you've edited this you would run
>
>    - netplan generate
>    - netplan apply
>
> Note: I've often noticed that things I define in /etc/plan aren't
> reflected in the gnome NetworkManager app even though I specified the
> renderer is NetworkManager. This can be confusing.
>
> The VPN gateway can specify the VPN details - this can be useful if you
> want an "always on" VPN connection. That's normally frowned on but I'm
> often running shell sessions to multiple systems and it would often be a
> pain to restore my work.
>
> It looks like netplan doesn't directly support iptables (for the gateway)
> but you can handle it in a script (or /etc/iptables/rules.v4). See
> https://feeding.cloud.geek.nz/posts/using-iptables-with-network-manager/.
>
> Bear
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20201208/e565959d/attachment.html>