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

[Jørn Åne]

Den 29.10.2018 13:23, skrev 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.

I support using routers for firewalling of clients, but I recommend that
the option to limit traffic *between* clients is kept.  This is
something that is handled within the server, so an external firewall
cannot limit this.


-- 
Jørn Åne
Systemutvikler

Uninett AS

jorn.dejong at uninett.no
+47 95 36 10 17

www.uninett.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://list.surfnet.nl/pipermail/eduvpn-deploy/attachments/20181031/3943e8f0/attachment.sig>