-----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----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
