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

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
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.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVu3z0AAoJEDg5KY9j7GZYcQcP/2fIXMXVi+g4rQCo96+fBsvw
ZOIj1YcVDTwA7LGe8qrMldIs8o39cS11X8KWYgyq/LtRHHGxX6xxtBSJrIACy3vl
OF72EZBVti5KMtubDkFe04Hx0TRAQiqdj5xa5cu7fqtNrOstgdFoOPPfyB54RWqp
hzQsWFc7IilmKLEIl3ich1XDbjJErQYW+Qd1IKDzo4eWvrPWoFGhOLxerZgVpJCh
8J2dzbPCd7AM7Yzt/q2EVzrQbt0gbQBjtaU3hLL2rnzd3NpAeUkPfH2n6J2LRTfo
npafuXmTjky/qVnlXZ/mD8SliLjrdnnVSt8sagOYsl6g71yIVx8DMLZ66JBX3IyW
ovdCv3o830ZCj1SBJtPSLw6fGq7Bm8bJtCp2yFnPmW3D/JadDAFvmAVouH6u8lGM
8AzKO/QfJg9h8rBnjNABKIx3aYVffa3jSttWaTk/oA9RhE5vqlRn8f5h+6Or/Sil
Foh5+LaS89QINfw5BEqo9svfQ/lEjM7NY7hLjggv5DAfhiV7rkpi1rrga1SLI5CO
3b+zDIx30m92mB5A0IoZ1+qFlJSuhZ3jLcx0fz9yzG+mk8QLMajeVOy4didiV6RL
FcX3/8ntDpZ9hbdocwP5Osdb+IkfWbNL4jU4jaCkEsRmo+G70OZ3JNRmx84Su1Bd
UAYqACOc2pU7hS8k31AW
=IPqV
-----END PGP SIGNATURE-----