Local network access when using ProxyVM as VPN gateway using iptables and CLI scripts?

[Michael Siepmann]

I've followed the instructions to "Set up a ProxyVM as a VPN gateway using iptables and CLI scripts" at https://www.qubes-os.org/doc/vpn/ and it's working well so far but I need to be able to access my local network 192.168.x.x. That worked when I was connecting to the VPN with Network Manager in my NetVM. Is there a way to configure that when using a ProxyVM as a VPN gateway? I'm guessing I need to do something in /rw/config/qubes-firewall-user-script in my VPN ProxyVM to configure iptables to allow bypassing the VPN for 192.168.x.x but I'm not sure how to do that. Any help will be greatly appreciated!

Best regards,

Michael Siepmann

--

Michael Siepmann, Ph.D.
The Tech Design Psychologist™
Shaping technology to help people flourish™
303-835-0501   TechDesignPsych.com   OpenPGP: 6D65A4F7
 

[Chris Laprise]

On 11/15/2017 10:17 PM, Michael Siepmann wrote:
>
> I've followed the instructions to "Set up a ProxyVM as a VPN gateway
> using iptables and CLI scripts" at https://www.qubes-os.org/doc/vpn/
> and it's working well so far but I need to be able to access my local
> network 192.168.x.x. That worked when I was connecting to the VPN with
> Network Manager in my NetVM. Is there a way to configure that when
> using a ProxyVM as a VPN gateway? I'm guessing I need to do something
> in /rw/config/qubes-firewall-user-script in my VPN ProxyVM to
> configure iptables to allow bypassing the VPN for 192.168.x.x but I'm
> not sure how to do that. Any help will be greatly appreciated!
>

Hi Michael,

You're not the first to ask about LAN access via a VPN VM. Various
posters in qubes-users have found ways around the anti-leak
configuration to access particular nets directly.

What I usually advise is to think of VPN proxy, sys-firewall or any
other proxyVM as Qubes network primitives: Let the VPN VM do its thing
in guarding against non-tunnel access, and use sys-firewall or specific
proxyVM to access the LAN. This implies that any given appVM can have
access to only one type of network (or, only one type at a time). This
IMHO is the best way.

OTOH, yes you can make the compromise in the VPN VM and allow non-tunnel
traffic. In the firewall script, you can start by commenting-out these
two lines:

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

This removes almost all leak protection, but should suffice for initial
testing. You may also have to add a route pointing to your local net
(see Linux "ip route" documentation) because the VPN may have added its
route as a default. If you wish to eventually reinstate the above
anti-leak rules you can try adding exceptions after those two (so they
will be listed _first_ in the FORWARD chain), for instance:

iptables -I FORWARD -o eth0 -d 192.168.0.0/16 -j ACCEPT
iptables -I FORWARD -i eth0 -s 192.168.0.0/16 -j ACCEPT

A word of caution: Once you start modifying rules like this its easy to
make mistakes that compromise security, even if you generally know what
you're doing. That's one reason to use the Qubes-oriented net security
model I mentioned initially. Another reason is, of course, that even
creating correct exceptions to tunnel enforcement opens you up to
certain kinds of threats. If your use case does not call for an appVM
accessing both VPN and LAN at the same time then there should be no
reason to make the compromise.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Michael Siepmann]

Hi Chris,

Thank you! I will try this and report back. My main use case here is
automatically doing an encrypted backup (with Borg Backup) of my files
once an hour to a NAS device, which in turn automatically copies the
backups to cloud storage at night, when I don't have competing needs for
the upload bandwidth. Another use case is file sync, e.g. with SyncThing
(which can work over the Internet, but much slower of course). However,
I can certainly see the security advantages of only letting an appVM
have access to one type of network, or only one type at a time.

[Michael Siepmann]

Hi Chris,

I got it working! The changes I've made (to allow access only to
192.168.9.x, not 192.168.x.x) are:

In my "sys-vpn" VPN Proxy VM...

...added the following lines to /rw/config/qubes-firewall-user-script,
after the "Block forwarding of connections through upstream network
device (in case the tunnel breaks)" section:

  #    Allow forwarding of connections through upstream network device
  #    if they're to 192.168.9.x
  iptables -I FORWARD -o eth0 -d 192.168.9.0/24 -j ACCEPT
  iptables -I FORWARD -i eth0 -s 192.168.9.0/24 -j ACCEPT

...added the following lines to /rw/config/vpn/qubes-vpn-handler.sh, at
the end of the "up)" case:

  # Allow access to home network for backup, etc.
  ip route add 192.168.9.0/24 via 10.137.1.1 dev eth0

...where 10.137.1.1 is the gateway for my "sys-vpn" VPN ProxyVM.

Please let me know if you see any problems with what I've done other
than the general security caveat you mentioned before.

Many thanks for your help!  I really appreciate it.

[Chris Laprise]

Glad I could help, Michael... And thanks for posting about your solution!

[Michael Siepmann]

On 11/21/2017 02:07 PM, Michael Siepmann wrote:

Michael Siepmann, Ph.D.
The Tech Design Psychologist™
Shaping technology to help people flourish™
303-835-0501   TechDesignPsych.com   OpenPGP: 6D65A4F7
 

On 11/16/2017 09:50 PM, Michael Siepmann wrote:

(I can see on the Web archive that Chris Laprise replied to the message above but for some reason I didn't get that email, so I'm replying to the most recent email I have.)

This is just an update about how I did the above after changing over to Chris' approach to use a full systemd config to manage VPN processes, which seems to have solved the problems I was having with the VPN not reliably resuming after waking from sleep:

https://github.com/tasket/Qubes-vpn-support

1. I first created a new VPN Proxy and followed Chris' instructions at the github URL above.
2. Once I'd confirmed everything was working without local network access, I added the two iptables lines above to the end of /rw/config/qubes-firewall-user-script.
3. I added the "ip route" line above to the middle of /rw/config/rc.local, immediately before the "Start tunnel service" section.