Unable to configure a persistent set of rules for iptables on a standalone proxyvm

[Jennifer Humes]

Hi everyone, thanks for the help on the last issue.

I created a standalone proxy VM.
The objective is for it to provide access to other computers through a VPN and have it drop all packets that would try to access the Internet without going through it.
It works perfect, but I'm not able to have it execute on restart. I could share it BTW, after all is working, could be useful for someone else.

After reading several posts on both groups, I followed this guide: https://wiki.qubes-os.org/wiki/UserDoc/ConfigFiles.
I tried with both /rw/config/rc.local, /rw/config/qubes-firewall-user-script and /etc/rc.local. In all cases, the scripts is set to be executable and it runs perfectly on reboot, since I added a file creation line and that one is working:

#!/bin/bash
sudo /sbin/iptables-restore > cat /rw/config/iptables
touch /etc/test
true

I added the "true", since I read somewhere on the group that without it, it wouldn't run. I don't understand why exactly, but it doesn't hurt.
So it seems that the problem is that a script is overwriting my iptables configuration after this one is run. It must be this way because if I run this script manually, the iptable config is loaded properly. Unless there's some weird issue I'm not seeing (iptables-restore is not run as root, so it fails, or some enviroment variables issue which I don't see).

Could anyone help me out with this? I'm very frustrated, have been with this problem for hours.

Thank you!

[cprise]

Hi Jennifer,

Qubes will definitely overwrite the firewall rules you set from a standard, boot-time script (at least it will for '-t filter' table in a proxy VM), so you need to either use qubes-firewall-user-script or tiptoe around the standard Qubes changes (I have done this in the past by using '-t mangle' instead, but that has its limits).

Also, did you mean to put '> cat /rw/config/iptables' instead of '< /rw/config/iptables' on the iptables-restore line?

When I setup rules in a proxy, I use direct iptables commands in a script. That way my changes will only be added to whatever Qubes thinks as necessary for the proxy to function (the Qubes additions are not a static, boot-time thing... they are dynamic and change when other VMs connect to the proxy). Using iptables-save/restore would have me worrying that I'd save some stale version of the Qubes-added rules and then keep restoring them.

OTOH, if you are not using iptables-save (only restore with 'noflush') *and* you are manually editing the contents of /rw/config/iptables, that would probably work. The whole form of the command I'd expect to see in a proxy VM is:

iptables-restore --noflush < /rw/config/iptables

(This is another area where I'd hope the wiki gets updated/expanded... current text leaves too many questions.)

[Jennifer Humes]

18.12.2014, 11:56, "cprise" <cpr...@gmail.com>:

Hi! Thank you very much for your reply.

It seems that the more I read about this, the more confused I get, LOL!

I was reading at /etc/rc.d/init.d/README that this system uses the new systemd.
I'm not familiar with it, but apparently, you can see all the services/scripts run at startup running systemctl.

Did that and I see that qubes-firewall.service has a "failed". It was my script at qubes-firewall-user-script that generated that error, if I disable execution for that, the error goes away.

Anyway, I thank you for the details about over writing the dynamically generated config, I'm sure that would be an issue.
But I first need to be able to get ANY configuration into iptables on boot reliably.

I even tried having an rc.local script at /rw/config that just runs:

sudo services iptables stop
sudo services iptables start

That, if run manually, replaces the lines sent by qubes to some of my own, that will obviously be faulty, but the point if that manually work but automatically doesn't.

Anyone has any ideas?
I'm thinking the sanest thing might be to create an AppVM or a NetVM and manually make it a proxy using iptables.

[Jennifer Humes]

OK, IT WORKS :D

No thanks to iptables, though! I hate that thing, haha.

Basically what I did is I created a rc.local that establishes a VPN tunnel on startup and then, removes the default route from the routing table.
That way, if for some reason the VPN gets disconnected, nothing gets exposed.
I also, just in case the VPN connection fails and I don't notice, added the route delete command again at the end, independent from the VPN.

1) /rw/config/rc.local does this:

#!/bin/bash
cd /home/user/Misc/VPN/
/home/user/Misc/VPN/vpn &
sleep 5

2) /home/user/Misc/VPN/vpn (--script-security 2 allows to execute scripts after connecting, --up runs the script)

#!/bin/bash
openvpn --config /home/user/Misc/VPN/TCP.ovpn --script-security 2 --up /home/user/Misc/VPN/routing &
sleep 2

3) /home/user/Misc/VPN/routing:

#!/bin/bash
/sbin/route del -net 0.0.0.0 gw 10.137.3.1

My question: is there any mechanism in Qubes that might generate another DHCP request and so, get the default gateway again? That would definetedly destroy completely my security.
Is that a risk?
Any other you guys can think of?

Thanks!

[cprise]

Its conceivable that DHCP client would run again if, say, you went into VM Manager settings for the proxy and changed its netvm setting... that would re-connect eth0 in the proxy to something else and your default gateway might be re-added.

The way I did it was to block forwarding for eth0 in the mangle table:
iptables -t mangle -I FORWARD 1 -o eth0 -j DROP
iptables -t mangle -I FORWARD 2 -i eth0 -j DROP

The Qubes firewall service doesn't try to manage the mangle table, so the rules stay put. This is in the /rw/config/rc.local BTW. To be extra sure, you could put them in your openvpn --up script right after:
iptables -t mangle -F FORWARD

You can also use 'iptables --check' to test for the presence of a rule and take action if its not there.


FYI, I did some tests with qubes-firewall-user-script and there are some cases where it doesn't run at all, such as in a Torvm proxy. Even if I disabled qubes-tor and enabled qubes-firewall that script didn't seem to run. I'm not sure if this is a bug. The script did run for me in a plain proxy VM.