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 <http://www.TechDesignPsych.com?id=esig> OpenPGP: 6D65A4F7 <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7&fingerprint=on&hash=on&op=vindex>
> On 11/16/2017 09:50 PM, Michael Siepmann wrote: >> On 11/16/2017 08:11 AM, Chris Laprise wrote: >>> 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. >>> >> 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. > 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. (I can see on the Web archive <https://groups.google.com/forum/#%21searchin/qubes-users/local$20network$20access%7Csort:date/qubes-users/HOuNHu6XT0M/1WS-ZJyTAAAJ> 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e171e071-9c69-35d0-51dd-83a406c5706f%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
