SOLVED! Thanks to Noel, I have a fix to block Strongswan client-to-client VPN traffic (thus isolating VPN clients).
I had two problems. The first was my default iptables FORWARD rules were in the wrong order. -A FORWARD -s 10.1.0.0/16 -d 10.1.0.0/16 -j REJECT -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT -A FORWARD -i ppp+ -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT -A FORWARD -p tcp -j ACCEPT -A FORWARD -p udp -j ACCEPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT The second problem is /usr/libexec/ipsec/_updown script case "up-client:iptables" adds client FORWARD ACCEPT rules to the 1st position above the REJECT. I fixed that by changing FORWARD 1 to FORWARD 4. Thus the VPN client rules go in position 4. # VPN client connects as 10.1.0.1 # _updown adds client ACCEPT rules in FORWARD position 4 [root@e20-Strongswan ipsec]# iptables -L | grep -A 10 FORWARD Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- 10.1.0.0/16 10.1.0.0/16 reject-with icmp-port-unreachable ACCEPT all -- anywhere anywhere policy match dir in pol ipsec ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED ACCEPT all -- 10.1.0.1 anywhere policy match dir in pol ipsec reqid 16724 proto esp ACCEPT all -- anywhere 10.1.0.1 policy match dir out pol ipsec reqid 16724 proto esp ACCEPT tcp -- anywhere anywhere ACCEPT udp -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED Chris -----Original Message----- From: Noel Kuntze [mailto:[email protected]] Sent: Thursday, October 10, 2013 11:00 AM To: 'Chris Strong' Subject: Re: [strongSwan] blocking Strongswan VPN client-to-client traffic? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Chris, The iptables rules are inserted by the default updown script, which is in (/usr)/lib/strongswan/. If you don't like its behaviour, you can edit it and put your own iptables rules and other commands in it. If you want to do that, you need to _copy_ it and alter the copy to your needs. Then put leftupdown=<path to your updown script(it needs to be executable, of course)> Regards Noel Kuntze On 10.10.2013 19:37, Chris Strong wrote: > Strongswan, > > How do I block client-to-client traffic in strongswan v4.6.4? I want to > completely isolate the VPN clients from each other. > > My implementation is simple. The closest example is > http://strongswan.org/uml/testresults4/pfkey/rw-cert/index.html > > When client VPN tunnels are connected to 'moon', roadwarrior 'carol' (in > random hotel#1) and roadwarrior 'dave' (in random hotel#2) can access each > other on their VPN tunnel assigned non-routable IPs! Forexample, if 'carol' > is running a web server that binds to her VPN assigned non-routable, 'dave' > canport scan and access 'carol' web server. > > How do I block traffic between all VPN clients (eg: 'carol' and 'dave')? I've > tried iptables INPUT, FORWARD, and OUTPUTbut have been unable to block the > client-to-client traffic. TheVPN client ACCEPT rules are added *above* the > REJECT rule I added. > > I've spent a great deal of effort getting 4.6.4 working and my attempts with > 5.x have failed, so please don't ask me to upgrade. > > The server configs are inline below. VPN clients get a 10.1.0.0/16 address > and can access each other when connected to the strongswan server. > > thanks, > Chris > > # /etc/sysconfig/iptables FORWARD rules > -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT > -A FORWARD -i ppp+ -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT > -A FORWARD -s 10.1.0.0/16 -d 10.1.0.0/16 -j REJECT > -A FORWARD -p tcp -j ACCEPT > -A FORWARD -p udp -j ACCEPT > -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > # This is what the rules look like before any VPN clients connect > # note the REJECT line position > $ iptables –L > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywhere policy match dir in pol ipsec > ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED > REJECT all -- 10.1.0.0/16 10.1.0.0/16 reject-with icmp-port-unreachable > ACCEPT tcp -- anywhere anywhere > ACCEPT udp -- anywhere anywhere > ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED > > # live iptables after 10.1.0.6 and 10.1.0.7 connect. > # note VPN client ACCEPT rules are added *above* the reject > # Firewall policies are processed top down, so the REJECT line does > absolutely nothing. > $ iptables –L > *snip* > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- 10.1.0.7 anywhere policy match dir in pol ipsec reqid 16660 > proto esp > ACCEPT all -- anywhere 10.1.0.7 policy match dir out pol ipsec reqid 16660 > proto esp > ACCEPT all -- 10.1.0.6 anywhere policy match dir in pol ipsec reqid 16652 > proto esp > ACCEPT all -- anywhere 10.1.0.6 policy match dir out pol ipsec reqid 16652 > proto esp > ACCEPT all -- anywhere anywhere policy match dir in pol ipsec > ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED > REJECT all -- 10.1.0.0/16 10.1.0.0/16 reject-with icmp-port-unreachable > ACCEPT tcp -- anywhere anywhere > ACCEPT udp -- anywhere anywhere > ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED > *snip* > > [root@e20-Strongswan etc]# cat strongswan.conf > # strongswan.conf - strongSwan configuration file > > charon { > > # number of worker threads in charon > threads = 32 > > # send strongswan vendor ID? > # send_vendor_id = yes > > plugins { > > sql { > # loglevel to log into sql database > loglevel = -1 > > # URI to the database > # database = sqlite:///path/to/file.db > # database = mysql://user:password@localhost/database > } > } > > # ... > } > > pluto { > dns1 = 10.1.0.253 > } > > libstrongswan { > > # set to no, the DH exponent size is optimized > # dh_exponent_ansi_x9_42 = no > } > > > [root@e20-Strongswan etc]# cat ipsec.conf > config setup > plutodebug=control > plutostart=yes > plutostderrlog=/var/log/pluto.log > Licht aus, Decke bis zur Nase, Heizung an. Könnte besser, könnte aber auch > schlechter. > nat_traversal=yes > uniqueids=yes > crlcheckinterval=60 > cachecrls=yes > strictcrlpolicy=yes > > ca $default > auto=add > > conn ios > type=tunnel > keyexchange=ikev1 > authby=xauthrsasig > xauth=server > left=%defaultroute > leftsubnet=0.0.0.0/0 > leftcert=serverCert.pem > leftfirewall=yes > right=%any > rightsourceip=10.1.0.0/16 > pfs=no > auto=add > > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVusuAAoJEDg5KY9j7GZY9HUQAI4HQdFwQxvgLEwsla+V8sZq n2dojNQf8LwfMmQulrh7opGSw0JeCNdpN+X6+YEJnHXHbi/b2Aa5a+d6Ik1TL48o Q7BCVLOnhncZYaWDBsh/nRp5p8/uByIv7DUG6fLQBhy1mqHzcp2aGE1PbLqLY8UJ damrPlwr4pl1cQQc2vngMlCsIYWKfVEjAOMF/vl/bftQ1jRCJ9WDiu3rl8ah084P 1QxUDeRCL0kBDHRbUdpS9cTZT4Csmwyej6nbKmg/1CZbus5HBXpu9Sm81sDf9Iah eHbGTC2Ck7qkxdWDc9Elg1Z2q1seJqfIobXVO9oX9Yisnbq40+SpGW0aHgZe4Rly VS7pPAmzCheCK8ruRWl4enMj8v6FC/hNJC10v0XHN17mlPGKoQw++kA40KKhwZYl eucYEHxDaU2ArHVux7c69qvtSibDhhIUKnIl2992gKMVIpTwPJQyRuTF6YsKckSn dArHMfgHKA05N7/lPniabptH4p7P+fTXpuhxFeyom7x5gN/ZsNd6PgDwPwwPzdaQ WMZeeC2dMWeRzzXzdCBJuF9H6C280FFj3/yQU+zcDEpyVRWSCHDSAPdQ9kRVmK6v X40uosZCjemqMvUOOlSbBcN9xehe08oZC7DW76rORxZ4R/AmWGEV8XxPLjA4EM9g 1HigkVeD8+b8hslM3YAD =uPMx -----END PGP SIGNATURE-----
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
