Feature #15582
open
Add option to automatically create rules to block VPN networks from existing via WAN interfaces
Added by Andrew Almond 4 days ago.
Updated 3 days ago.
Description
It's a known issue that traffic intended for VPN networks can be sent out the WAN interfaces if the VPN tunnel is down, which causes states to be established on the WAN interfaces. This then delays or prevents traffic from being sent over the VPN tunnel when it is re-established.
The recommended solution is to create floating rules that block all traffic from private/VPN networks from going out the WAN interfaces. I've done this and it seems to help.
It would be great if there was an option either globally or per-interface that would create the rules automatically, similar to the Block private and Block Bogon options. Maybe it could use a built-in IP alias, which the user could then customize as needed?
On a related note, the VPN leakage issue and floating rule setup needs to be documented so that people are aware of this issue.
I've only ever seen this issue mentioned twice, once by Jim Pringle and and think the other was a Strongswan forum somewhere.
Ok it's great that it's already documented.
However, I've read the documentation a lot (particularly the VPN setup sections) and would never have associated a document in the pfSense® software Configuration Recipes section titled Preventing RFC 1918 Traffic from Exiting a WAN Interface as something relevant to traffic issues with IPsec VPNs.
Further compounding the problem is that when troubleshooting a one-way traffic issue over a VPN, it didn't even cross my mind that the the firewall would attempt to send the traffic out the WAN and establish a state that persists even after disconnecting and reconnecting the VPN.
Just adding a blurb in VPN section with a link to that document would be a huge help. Maybe add a note to check the WAN interfaces for states with private/VPN IPs when troubleshooting intermittent VPN traffic issues?
- Subject changed from Add option to automatically create rules to block private networks from existing via WAN interfaces to Add option to automatically create rules to block VPN networks from existing via WAN interfaces
I thought we already had an issue for this open but I'm not seeing one. We've talked about doing this before, but it's a lot more complex than it appears on the surface.
While an option to block all private networks outbound isn't viable as a blanket policy, we could probably craft something to block traffic from exiting from the wrong path. For example it already tracks most (but not all) VPN-connected networks in the internal vpn_networks table, we could maybe key off that to stop traffic in that table from exiting a non-VPN WAN.
The problem then is properly determining which interfaces are actual WANs and not VPNs or internal links, which isn't trivial in a good portion of cases. It's not as simple as checking if a WAN has a non-private address since some WANs use private addresses for the next hop. You can't just use any interface with a gateway since that would also break lots of internal routing/private links/cross connect type scenarios. Can't just assume it's the default gateway interface since some people run their default gateways over VPNs. And so on, and so on. And making people manually list the WANs to block goes against the idea of automating it.
Hence the existing document and having people craft their own rules to cover these scenarios.
Jim, thanks for the explanation. Now, I understand the complexity of this issue better.
The simplest improvement would be to add a note on the VPN page to mention the leakage issue and a link to the Preventing RFC 1918 Traffic from Exiting a WAN Interface page. This would increase awareness, as right now there is no obvious relationship between the two pages/issues.
Would a possible solution be:
- Have the system create a visible IP alias like
private_networks or have the user create one;
- Put a checkbox on each interface labelled
Prevent defined private networks from exiting this interface;
- The system automatically creates the necessary rules based on the above settings;
I feel that this would be a user-friendly improvement without all the complexities of the system doing everything automatically.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by