[eduVPN-deploy] Removal of packet filtering for VPN client traffic

[François Kooman]

Hi all,

TL;DR: plan to remove firewall/filtering *for VPN client traffic* from
the server, delegating this to a switch/router in network.

Currently, the VPN server allows for (limited) filtering of traffic
going to/from the VPN clients which is not a "complete" solution to
filter traffic. For example: it is currently not possible to block
outgoing tcp/25. Instead of adding this functionality, I'd like to take
a different approach: remove all filtering capability and delegate this
to network equipment/VM platform.

Currently, the filtering is both implicit, and explicit: NAT is the
implicit filter. It block incoming traffic somewhat, unless matched by
the NAT state tracking. It is also explicit, by blocking certain
(outbound) traffic, like the SMB/CIFS ports related to Windows file and
printer sharing.

In addition, traffic between VPN clients can also blocked, this is
currently the default. Outbound VPN client traffic can also be blocked,
depending on the destination addresses. This seemed like a valid use
case when the project started, however, we are not aware of any
deployment where this is actually used/required.

In order to reduce the complexity, and increase the performance of the
VPN server, the plan is to remove some of this filtering ability from
the server software:

1. remove inbound/outbound firewall for VPN client traffic, allowing all
traffic (in the NAT scenario effectively nothing would change...);
2. remove restrictions for client to client traffic;
3. remove firewall rules that limit outgoing traffic based on
destination (in not-the-default-gateway scenarios);
4. have single/simple "NAT" configuration for the default gateway
outbound interface without any additional filtering

It turns out that a much better solution is to do filtering for VPN
client traffic in the network equipment, i.e. switch or router or VM
platform, dedicated for this purpose. Most organizations have a (border)
firewall that takes care of this already! Duplicating this in the VPN
server is redundant, hard to keep in sync, and is a performance hit.

In addition: the firewall capabilities are currently not used by any of
the bigger deployments. It turns out, limiting traffic is done on the
"target" networks, i.e. allow traffic only from certain IP ranges.
Filtering this on the VPN server itself is redundant and possibly
dangerous if there is an issue with the firewall.

Please let me know if you have any remarks/questions, or have good
reasons for keeping the firewall in the VPN server, e.g. scenarios where
it can't be replaced by dedicated router/firewall(s).

In the next weeks I'll plan to start rewriting the firewall code.

Regards,
François