[strongSwan] Avoid leakage of packets addressed to/from private IP space

Noel Kuntze noel at familie-kuntze.de
Fri Jul 31 15:49:43 CEST 2015

Hash: SHA256

Hello Vitaly,

I read through your post and have criticism for you:

You should drop all packets with no matching IPsec policy,
if their target is an RFC1918 address space and the interface
the packet goes out of is attached to the WAN.

The reason I used an ipset and not -s -d in the email
you referenced under "IPsec: dropping packets without a matched policy"
is, that you can easily change the content of the IPset without
having to touch your iptables rules. ipsets have distinct advantages[1]
to pure iptables based approach to listing networks and ports.

Also, several arguments to -s and -d in iptables expand to several rules with all
combinations of listed networks and hosts. This means that if you have a rule with
two arguments to -s and two arguments to -d, those will result in 4 rules in iptables.

Also, you're mixing the use of iproute2 and bridge-utils, you even ask
the user to install the latter.  iproute2 can create bridge devices just fine.
The current only use cases I know of, for which brctl
is really needed, is to enable stp or show information
about the stp state of the bridge, but you're not using that functionality.
As you already use custom ifup and ifdown hooks in the interfaces
file, you can just continue using that to script the creation of the bridge.
There's no need to use the native syntax of the file, as it uses the old net-tools, which
is quite bad, but Debian-esque.

Furthermore, you're scripting around ebtables.This is bad for many reasons[2].
There are ebtables-save and -restore, which work exactly the same way
as iptables-save and -restore. There is no reason to script around ebtables.

Additionally, you don't even /need/ ebtables. You can filter everything
in *filter FORWARD. Adding a bridge device and ebtables rules
add unnecessary complexity on top.
Using ebtables to filter and log packets, that the writer of the rule set forgot to
take care of, does not except him from duty to take care of his rule set. A good
way to filter packets destined for RFC1918 address space is to simply put the blocking rules on
top of the rule chain of *filter FORWARD and use an ipset to store the different networks. You can even add
explicit non matching entries to the list, so you can except certain networks or hosts from the rule.

[1] http://sfvlug.editthis.info/wiki/Things_You_Should_Know_About_Netfilter#Using_ipsets
[2] http://sfvlug.editthis.info/wiki/Things_You_Should_Know_About_Netfilter#Use_iptables-save_and_iptables-restore

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 31.07.2015 um 13:20 schrieb Vitaly Repin:
> Hello,
> I've recently faced an issue with package leakage from the clients
> connected through IPSEC. (The packages addressed to VPN address space
> were "leaking" through external interface).
> The problem is now solved and I've documented complete solution here:
> http://vrepin.org/vr/IPsec-PacketLeakage/
> I hope it can be useful for other strongwan users.

Version: GnuPG v2


More information about the Users mailing list