On 10/14/2016 12:32 AM, Chris Laprise wrote:
> On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote:
>>>>> * Interdependent packet marking, detection and routing rules are
>>>>> needlessly complex
>>>> FWMARK was the only way to get blackholing to work reliably without
>>>> interference from the Qubes OS firewalling system.
>>> So you added complexity where simply blocking all forwarding to/from
>>> eth0 would have sufficed.
>> Not really. I implemented the simplest and least-invasive solution I
>> could think of. It's four directives:
>> 1. Instruct the routing engine to route all packets from downstream VMs
>> to use table 78. This happens very early during boot, right after the
>> Qubes OS default firewall rules are loaded, and so it happens that VMs
>> cannot leak.
>> 2. Tell table 78 to route all traffic to the VPN if the VPN interface is
>> active, and to blackhole all traffic if the VPN interface goes down.
>> This is actually quite cool, because there's no need to clean up
>> anything if the VPN fails — the routes disappear when the TUN/TAP device
>> goes away, leaving the blackhole route active.
>> 3. Add two firewall rules directing all DNS requests from downstream VMs
>> to the DNS servers of the VPN.
>> I think, in my humble opinion, that this compares /quite favorably/ with
>> (the doc) asking the user to write several scripts, all of which make
>> much more invasive iptables modifications, while still allowing the VPN
>> server to muck with the system routing table, a practice which under
>> some circumstances could cause the ProxyVM itself to use the wrong DNS
>> servers, or to fail to reconnect to the VPN.
>> Additionally, I see that some of the tables that the doc's scripts
>> modify are actually tables that the Qubes firewall may revert to their
>> original state, so it's quite easy for a firewall config change to blow
>> those rules up, leaving the user with a leaky VPN. Granted, the
>> firewall config change will only last about a half a second, because the
>> user firewall script will be invoked afterwards, but during that
>> half-second, traffic can leak via the eth0 route. OOPS!
> Now that is something interesting. So the Qubes firewall is supposedly
Nope. It's actually pretty good, and it was the inspiration for my
work. Getting leakproof VPNs is a hard job. The official documentation
for the firewall is as good as you can get, without hard core networking
> And we can let most users suffer whatever consequences when they block
> traffic with sys-firewall, because only our specific VPN application
I don't know what you mean. "Most users", "suffer", "consequences" when
they "block traffic". I have zero idea what this means with regards to
my work. Most users don't actually write shell scripts to do basic
things like VPN. "Most users" are not even the target of work like VPN
systems. The target market for such work is users who want provable
privacy. That is the sort of work that I endeavored to do, and now I
have delivered it.
> Keeping in mind that the default policy of FORWARD is DROP, we should
> also consider whether a stream of iptables commands is too slow to be
Yes, the document should probably be updated to reflect that.
> And if so, ask why 1) the user firewall rules are in script format;
That isn't the case within Qubes OS. Qubes OS firewall adds / changes
rules atomically via iptables-restore.
> Or why 2) the commands aren't all combined for an iptables-restore;
They are in Qubes OS.
IF you are critiquing my work again, then I have to say you are
technically correct, as the DNS rules my work adds (during OpenVPN "up")
are not atomically added via iptables-restore.
That fact is not relevant to the promise of leak-proofness that my work
makes. The only *relevant* rules that get added during VPN connection,
are two DNS rules. Any DNS packets sent by downstream VMs will be
blackholed in the meantime, so, well, leakproof like I said from the
beginning. It's okay to flush the specific routing table for DNS that
my program creates, and then to add rules non-atomically, as DNS packets
coming in between the flush and the rules will get dropped and not
routed anywhere useful.
If you look closely at my work — this is not an accident, but a
deliberate outcome of my study of the problem — during OpenVPN "up", the
DNS rules are added before the routes are added, which has the side
effect of DNS packets being routed nowhere until the routes are added.
So non-atomic modifications to the firewall are fine in this case. It's
all in the `qubes-vpn-interface-control.in` script for anyone to see.
You are welcome to verify these claims with tcpdump (I did it too).
You are also welcome to send pull requests to make the rule addition atomic.
> Or why 3) the chains aren't started with a temporary REJECT while they
> are being populated. ANY. ONE. Of these will address the issue for
> VPNs and all the other use cases.
No need to, because the DNS packets get blackholed until the rules are
Oops about what? Unlike the official Qubes VPN documentation, which
counsels people to write scripts that make non-atomic modifications to
their firewall, which actually and demonstrably have a leak between
Qubes firewall updates and VPN rules setup, my work doesn't leak traffic
in-between the addition of iptables rules.
(See why the custom routing table is useful?)
I mean, this you could verify with tcpdump. Which I did. So what are
you oopsing about? Or are you having a kernel panic in your head? :-)
> Here is bog-standard advice for properly handling firewall rules in
Thank you. I await the pull request that implements them :-D
Now, if you could tone down the gratuitous arseholeish behavior, and
substitute it with actual actionable evidence for your aversion to my
work, or better yet, improvements to my code, that would be amazing.
Let's see if that positive change in behavior materializes.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.