5 ms·

You wrote three different ways to end up with all traffic dropped and a broken VPN connection. Traffic sent to the VPN interface gets encapsulated by the VPN c

You wrote three different ways to end up with all traffic dropped and a broken VPN connection. Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic. You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing traffic which is already cloaked by the VPN software (or not cloaked, but used to establish/maintain the tunnel itself). That second category is a bit complicated, because you need to be able to route to the VPN server regardless of which network you're connected to - and the DHCP server tells you how to do that.

banister 2y ago
Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint. Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before the VPN comes up. Source: i've implemented this dozens of times (and you probably have too, it sounds like) so let's not quibble over the details ;)
- Borealid 2y ago
  If you're connected to a random network, whose configuration you don't know in advance, how do you route packets to your VPN server? The usual answer is that the network's router tells you how to do that, by supplying DHCP options. The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing". The DHCP server inserts rules into the host routing table, and the only software using those rules is the VPN client for its management and tunnel traffic. Otherwise, what if the network to which you connect says "the next hop for all internet traffic is 10.10.10.10"? You need to respect that rule when sending traffic to your VPN server, and ignore it for applications whose traffic will be tunneled.
  - banister 2y ago
    Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table. * Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. These also get added to your routing table * Step three - You connect your VPN. The VPN will bring up a firewall. It will also bring up `128/1` and `0/1` routes that point at the VPN tunnel. The VPN tunnel now takes over the default route. This firewall will block all traffic that's not on the tun device (the VPN interface). Further, it will whitelist the VPN endpoint IP and create a route for it (it can do this since it already received the default gateway from the DHCP server) * Step four - Your host starts sending traffic - either this traffic will go through the VPN tunnel (the default route) OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets). * Step five - All traffic that would go down the malicious option 121 routes are BLOCKED by the firewall rule. Hence nullifying the TunnelVision exploit. That's all. Done. Where's the complexity in that? As i said before i've done this dozens of times. I'm talking from experience. I know this works. Further you say: > The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing". You are aware we're talking about consumer VPNs right? The majority of users are on Windows and Mac. Neither of those OSes support multiple routing tables. Only Linux supports multiple routing tables. You're also just plain wrong - as i demonstrated above - you CAN just configure a firewall rule and it WILL just work properly. Again, i'm talking from experience.
    - Borealid 2y ago
      I think you missed a step in your progression. Step one, you connect to the network and get routes. Step two, you connect your VPN. Step three, your host starts sending traffic. At this point, your firewall rules are now active and dropping any traffic you've told them to. Step four, you renew your DHCP lease and get new routes via option 121. Those routes might be malicious, or they might not. One of three things is true at step four. Either: A. Your firewall rules will block all traffic over the new routes B. Your firewal rules will not block any traffic over the new routes C. Your firewall rules will block some subset of traffic over the new routes If A is true, then your VPN tunnel goes down (undesirable), as the VPN server can no longer be contacted. If B is true, then you are vulnerable to the TunnelVision exploit. If C is true, and the subset of traffic blocked is exactly the subset intended to route over the VPN but maliciously diverted, then the VPN tunnel goes down because the firewall rules are blocking its traffic. If C is true, and somehow the firewall rule is rewriting the traffic that's pointed not-over-the-VPN to be instead routed over the VPN (by using NAT?), then the VPN tunnel stays up and there is no problem. I'd be interested in seeing the set of firewall rules that will let the VPN tunnel stay up, with management traffic going over the added-after-the-tunnel-was-brought-up next-hop, and tunneled traffic continuing to flow ignoring the new route. I haven't seen those rules in the past so if you have experience writing them, please show me. Personally I've only used Linux multiple routing tables to plug this leak. EDIT: formatting

banister 2y ago

Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint. Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before the VPN comes up. Source: i've implemented this dozens of times (and you probably have too, it sounds like) so let's not quibble over the details ;)

Borealid 2y ago
If you're connected to a random network, whose configuration you don't know in advance, how do you route packets to your VPN server? The usual answer is that the network's router tells you how to do that, by supplying DHCP options. The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing". The DHCP server inserts rules into the host routing table, and the only software using those rules is the VPN client for its management and tunnel traffic. Otherwise, what if the network to which you connect says "the next hop for all internet traffic is 10.10.10.10"? You need to respect that rule when sending traffic to your VPN server, and ignore it for applications whose traffic will be tunneled.
- banister 2y ago
  Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table. * Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. These also get added to your routing table * Step three - You connect your VPN. The VPN will bring up a firewall. It will also bring up `128/1` and `0/1` routes that point at the VPN tunnel. The VPN tunnel now takes over the default route. This firewall will block all traffic that's not on the tun device (the VPN interface). Further, it will whitelist the VPN endpoint IP and create a route for it (it can do this since it already received the default gateway from the DHCP server) * Step four - Your host starts sending traffic - either this traffic will go through the VPN tunnel (the default route) OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets). * Step five - All traffic that would go down the malicious option 121 routes are BLOCKED by the firewall rule. Hence nullifying the TunnelVision exploit. That's all. Done. Where's the complexity in that? As i said before i've done this dozens of times. I'm talking from experience. I know this works. Further you say: > The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing". You are aware we're talking about consumer VPNs right? The majority of users are on Windows and Mac. Neither of those OSes support multiple routing tables. Only Linux supports multiple routing tables. You're also just plain wrong - as i demonstrated above - you CAN just configure a firewall rule and it WILL just work properly. Again, i'm talking from experience.
  - Borealid 2y ago
    I think you missed a step in your progression. Step one, you connect to the network and get routes. Step two, you connect your VPN. Step three, your host starts sending traffic. At this point, your firewall rules are now active and dropping any traffic you've told them to. Step four, you renew your DHCP lease and get new routes via option 121. Those routes might be malicious, or they might not. One of three things is true at step four. Either: A. Your firewall rules will block all traffic over the new routes B. Your firewal rules will not block any traffic over the new routes C. Your firewall rules will block some subset of traffic over the new routes If A is true, then your VPN tunnel goes down (undesirable), as the VPN server can no longer be contacted. If B is true, then you are vulnerable to the TunnelVision exploit. If C is true, and the subset of traffic blocked is exactly the subset intended to route over the VPN but maliciously diverted, then the VPN tunnel goes down because the firewall rules are blocking its traffic. If C is true, and somehow the firewall rule is rewriting the traffic that's pointed not-over-the-VPN to be instead routed over the VPN (by using NAT?), then the VPN tunnel stays up and there is no problem. I'd be interested in seeing the set of firewall rules that will let the VPN tunnel stay up, with management traffic going over the added-after-the-tunnel-was-brought-up next-hop, and tunneled traffic continuing to flow ignoring the new route. I haven't seen those rules in the past so if you have experience writing them, please show me. Personally I've only used Linux multiple routing tables to plug this leak. EDIT: formatting