[strongSwan] *FIXED* blocking Strongswan VPN client-to-client traffic?

[Chris Strong]

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 at 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:noel at familie-kuntze.de]
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 at 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 at 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
> Users at lists.strongswan.org
> 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-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20131010/c94c88be/attachment.html>