NetVM without firewall, no PING from outside?

[Jarle Thorsen]

I have a NetVM connected to the local network only, no Internet connection. The NetVM correctly gets it's IP settings via DHCP from the DHCP server on local network:

$ ifconfig
enp0s0f0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether a0:36:9f:97:ce:24 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp0s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.1.233 netmask 255.255.0.0 broadcast 10.0.255.255
inet6 fe80::9934:506d:1243:9213 prefixlen 64 scopeid 0x20<link>
ether a0:36:9f:97:ce:26 txqueuelen 1000 (Ethernet)
RX packets 155843244 bytes 227740975446 (212.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 97508817 bytes 32454133642 (30.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 52 bytes 3644 (3.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 52 bytes 3644 (3.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vif7.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.137.4.1 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::fcff:ffff:feff:ffff prefixlen 64 scopeid 0x20<link>
ether fe:ff:ff:ff:ff:ff txqueuelen 32 (Ethernet)
RX packets 80035111 bytes 775715569 (739.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 155646140 bytes 60288462 (57.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vif9.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.137.4.1 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::fcff:ffff:feff:ffff prefixlen 64 scopeid 0x20<link>
ether fe:ff:ff:ff:ff:ff txqueuelen 32 (Ethernet)
RX packets 76996 bytes 5962260 (5.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 36328 bytes 3932143 (3.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Basically I want no filtering of packets in/out through this NetVM. Both the NetVM and any VM connected through it can ping outside IPs, but no machines on the local network can PING into Qubes.

Do I need to set up a ProxyVM to allow all traffic in?

[Unman]

I suggest you read the docs:
www.qubes-os.org/doc/firewall has a section on allowing traffic in to
qubes.

But this may not be what you want. It reads as if you want to have
sys-net operating as a router. You can do this quite simply by changing
the iptables configuration and using proxy arp to make sure that the
external network sees the qubes behind the router.
Alternatively you could use the netvm as a gateway to the network of
qubes, and make sure that THAT route is propagated on your internal
network.

I don't know what level of knowledge you have at the moment, but
there's plenty of advice online. If you want your qubes to be visible
to the network then you want to cut out most of the filtering and nat
options in sys-net. You can do this by using a dedicated template with
new firewall rules and routing set, or by making the changes in rc.local
- you will want to disable the qubes-firewall service to make sure that
your custom configuration isn't updated when you attach new qubes to
the netvm.

[Jarle Thorsen]

Unman:

> I suggest you read the docs:
> www.qubes-os.org/doc/firewall has a section on allowing traffic in to
> qubes.

Thank you for the link. It provided a good foundation.

> But this may not be what you want. It reads as if you want to have
> sys-net operating as a router. You can do this quite simply by changing
> the iptables configuration and using proxy arp to make sure that the
> external network sees the qubes behind the router.
> Alternatively you could use the netvm as a gateway to the network of
> qubes, and make sure that THAT route is propagated on your internal
> network.

Thank you, it seems like using proxy arp is the way to go for me. That way I can still use a dynamic address for my NetVM.

[Jarle Thorsen]

I'm getting back to this thread, still haven't got everything working:

My NetVM is connected to a local network 10.0.0.0/16, and gets a dynamic IP via DHCP.

AppVMs connect directly to the NetVM, without any firewall, and all firewall rules has been removed from NetVM.

All networking is now working fine, both between AppVMs and from AppVMs and into the 10.0.0.0/16 network.

Now I need to have the AppVMs available from the 10.0.0.0/16 network...

Where do I need to enable arp_proxy to make this happen? Only on the NetVM interface connected to the 10.0.0.0/16 network, or also on the vif interfaces on the NetVM, or in the AppVMs also??

[Manuel Amador (Rudd-O)]

Qubes-network-server takes care of this for you.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Unman]

On Fri, Feb 17, 2017 at 06:01:14PM -0800, Manuel Amador (Rudd-O) wrote:
> Qubes-network-server takes care of this for you.
>
> On February 14, 2017 2:02:18 AM PST, Jarle Thorsen <jarlet...@gmail.com> wrote:
> >> Unman:

> >> Thank you, it seems like using proxy arp is the way to go for me.
> >That way I can still use a dynamic address for my NetVM.
> >
> >I'm getting back to this thread, still haven't got everything working:
> >
> >My NetVM is connected to a local network 10.0.0.0/16, and gets a
> >dynamic IP via DHCP.
> >
> >AppVMs connect directly to the NetVM, without any firewall, and all
> >firewall rules has been removed from NetVM.
> >
> >All networking is now working fine, both between AppVMs and from AppVMs
> >and into the 10.0.0.0/16 network.
> >
> >Now I need to have the AppVMs available from the 10.0.0.0/16 network...
> >
> >Where do I need to enable arp_proxy to make this happen? Only on the
> >NetVM interface connected to the 10.0.0.0/16 network, or also on the
> >vif interfaces on the NetVM, or in the AppVMs also??
> >

This really isn't very helpful to someone who is trying to understand
what is happening. Perhaps the need for brevity prevented a fuller
answer. But just saying there's a tool, (although I understand your
wish to promote your software) isn't the way to go imo.

Jarle - there are a few things you could do. One of them would be to
distribute a static route using your DHCP server - implementing
a classless static route if your server supports it would be best. You
would need to put the external iface of the netVM as the gateway to the
internal 10.137.0.0/16 network. This won't be easy with DHCP unless you
put a reservation in place.

Alternatively you use proxy arp on the external interface of the netVM,
as you suggest. You don't need it on the vif interfaces because you
have the relevant routing information in the netVM. (As you are
connecting qubes directly to the netVM these routes will be set up
automatically. You can check this with 'ip route' - If you DID use a
firewall you would need to add a static route on the netVM with the fw
as gateway to the qubes connected to it.)

It may be that Rudd-0's tool will do this for you. I dont know.

unman

[Jarle Thorsen]

Manuel Amador (Rudd-O):

> Qubes-network-server takes care of this for you.

Yes, I know about Qubes-network-server, but I was hoping to get this working without requiring static IPs for AppVMs, and also better support for Windows VMs.

[Jarle Thorsen]

Unman:

> Jarle - there are a few things you could do. One of them would be to
> distribute a static route using your DHCP server - implementing
> a classless static route if your server supports it would be best. You
> would need to put the external iface of the netVM as the gateway to the
> internal 10.137.0.0/16 network. This won't be easy with DHCP unless you
> put a reservation in place.
>
> Alternatively you use proxy arp on the external interface of the netVM,
> as you suggest. You don't need it on the vif interfaces because you
> have the relevant routing information in the netVM. (As you are
> connecting qubes directly to the netVM these routes will be set up
> automatically. You can check this with 'ip route' - If you DID use a
> firewall you would need to add a static route on the netVM with the fw
> as gateway to the qubes connected to it.)

So my local network is 10.0.0.0/16 and default GW for all DHCP clients (including my NetVM) is 10.0.0.7

The dynamic IP of the NetVM might be 10.0.1.23. So if a client on my "outside" network try to contact an AppVM (10.137.4.23 for example), will it send an arp-request (letting arp_proxy do it's trick), or will it just send the packet to default GW (who currently has no route to 10.137.4.0/24)?

[Unman]

Doh, I've only just realised that your network is class B - so proxy arp
wont work as arp doesn't cross networks. Shouod have read nmore
carefully. Sorry to waste your time.

Yes, you're right - the packets will go to the default GW and you need
to have a route on there to the GW to the qubes - ie the IP of sys-net.
I still think that a better method would be to give out a route via DHCP
so all clients have that route, but it depends on you being able to do
classless static routing and using a DHCP reservation on sys-net.

Otherwise you need sys-net to broadcast a route which will be picked up
by the default GW on your 10.0/16 network.

cheers

unman