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. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e80071ff-f740-4de7-25a1-89ddf0798647%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
