On 11/21/2017 04:07 PM, Michael Siepmann wrote:
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.
Glad I could help, Michael... And thanks for posting about your solution!
--
Chris Laprise, [email protected]
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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/f8584f8d-584f-e3ef-ad1c-858061d7f536%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
