[strongSwan] Is a chained client-server VPN possible?

Noel Kuntze noel at familie-kuntze.de
Mon Dec 29 20:24:09 CET 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Tim,

Please ensure that the plugin is loaded. Look at the list of loaded modules
in the output of "ipsec statusall".

Furthermore, check the negotiated traffic selector to see if the two subnets are negotiated.
The updown script will add forward rules for all possible combinations of subnets.

Mit freundlichen Grüßen/Regards,
Noel Kuntze

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

Am 29.12.2014 um 20:19 schrieb Tim Soderstrom:
> Hmm made the iptables change, though no real change in any chaining behavior.
>
> ########################
> root at vpn:~/bin# iptables -t nat --list
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination        
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination        
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination        
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination        
> SNAT       all  --  anywhere             anywhere             policy match dir out pol none to:172.21.0.2
> ########################
>
> And yep I also have cisco_unity set to yes:
>
> ########################
> root at vpn:/etc/strongswan.d# cat charon.conf
> charon {
>   cisco_unity = yes
>   crypto_test { }
>   host_resolver { }
>   leak_detective { }
>   processor {
>     priority_threads { }
>   }
>   tls { }
>   x509 { }
>   dns1 = 172.21.0.2
>   install_routes = yes
> }
> ########################
>
> *scratches head* Is it the lack of forwards maybe? Upon connecting this is what I get added to the FORWARD chain:
>
> ########################
> root at vpn:/etc/strongswan.d# iptables --list FORWARD
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination        
> ACCEPT     all  --  172.22.99.100        172.23.0.0/16        policy match dir in pol ipsec reqid 2 proto esp
> ACCEPT     all  --  172.23.0.0/16        172.22.99.100        policy match dir out pol ipsec reqid 2 proto esp
> ACCEPT     all  --  172.22.99.100        172.21.0.0/16        policy match dir in pol ipsec reqid 2 proto esp
> ACCEPT     all  --  172.21.0.0/16        172.22.99.100        policy match dir out pol ipsec reqid 2 proto esp
> ########################
>
> Thoughts?
>
> Tim
>
> P.S. Yep realize my iptables Bash script isn’t standard. I’ll use save/restore functionality but do like to have a base template that’s a bit easier to read which I can comment on and do looping, etc. On the VPN server, since running that script flushes the rules, I’m really just using it as a base document and try to make changes the proper way. At least I’m not using ufw :)
>
>> On Dec 29, 2014, at 12:50 PM, Noel Kuntze <noel at familie-kuntze.de> wrote:
>>
>>
> Hello Tim,
>
> You need to except the packets that are supposed to be tunneled from NAT, not the esp packets.
>
> Replace your
> "iptables -t nat -A POSTROUTING -o eth2 ! -p esp -j SNAT --to-source 172.21.0.2"
> with "iptables -t nat -A POSTROUTING -o eth2 -m policy --pol none --dir out -j SNAT --to-source 172.21.0.2"
> Assuming you use the netlink backend, of course.
> I think your SNAT breaks it, or you are not using CISCO UNITY. Excepting traffic from NAT in the correct way
> helps obviously. Check if the unity plugin is loaded and "charon.cisco_unity" is set to "yes"
>
> Furthermore, using iptables directly to configure the firewall is bad. Use iptables-save and iptables-restore,
> as well as their respective counterparts for IPv6.
>
>
> Mit freundlichen Grüßen/Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 29.12.2014 um 19:31 schrieb Tim Soderstrom:
> >>> I did a but of obfuscation here and removed the additional user entries but it is otherwise complete:
> >>>
> >>> ###########################
> >>> version 2
> >>>
> >>> conn %default
> >>>    ikelifetime=60m
> >>>    lifetime=12h
> >>>    leftfirewall=yes
> >>>    left=%any
> >>>    leftid="C=US, O=My VPN, CN=vpn.example.com"
> >>>    leftcert=vpn.example.com-host.crt.pem
> >>>    leftsubnet=172.21.0.0/16
> >>>    leftdns=172.21.0.2
> >>>    dpdaction=hold
> >>>
> >>> conn Example-Site-To-Site-x509
> >>>    keyexchange=ikev2
> >>>    leftid=@vpn.example.io
> >>>    leftsubnet=172.21.0.0/16,172.22.99.0/24
> >>>    right=1.2.3.4
> >>>    rightid="vpn-dc2.example.io"
> >>>    rightsubnet=172.23.0.0/16
> >>>    auto=route
> >>>
> >>> conn Example-Client-OSX
> >>>    keyexchange=ikev1
> >>>    aggressive=no
> >>>    ikelifetime=24h
> >>>    lifetime=24h
> >>>    inactivity=12h
> >>>    authby=xauthrsasig
> >>>    xauth=server
> >>>    leftauth=pubkey
> >>>    leftsubnet=172.21.0.0/16,172.23.0.0/16
> >>>    right=%any
> >>>    rightauth=pubkey
> >>>    rightauth2=xauth
> >>>    auto=add
> >>>
> >>> conn example-Client-OSX-user1
> >>>    also=example-Client-OSX
> >>>    rightsourceip=172.22.99.100
> >>>    rightsubnet=172.22.99.100
> >>>    rightcert=user1.crt.pem
> >>>
> >>> …
> >>>
> >>> ###########################
> >>>
> >>> Here is also my base iptables configuration:
> >>>
> >>> ###########################
> >>> #!/bin/bash
> >>>
> >>> ## IPv4
> >>> iptables --flush
> >>> iptables --flush -t nat
> >>>
> >>> # NAT Routing
> >>> iptables -t nat -A POSTROUTING -o eth2 ! -p esp -j SNAT --to-source 172.21.0.2
> >>>
> >>> # Services Chain
> >>> iptables -X SERVICES
> >>> iptables -N SERVICES
> >>> iptables -A SERVICES -p ICMP -s 172.21.0.0/16 -j ACCEPT
> >>> iptables -A SERVICES -p ICMP -s 172.23.0.0/16 -j ACCEPT
> >>> iptables -A SERVICES -p TCP -s 1.2.3.4 --dport 22 -j ACCEPT
> >>> iptables -A SERVICES -p TCP -i eth2 --dport 22 -j ACCEPT
> >>> iptables -A SERVICES -p UDP --dport 500 -j ACCEPT
> >>> iptables -A SERVICES -p UDP --dport 4500 -j ACCEPT
> >>> iptables -A SERVICES -p esp -j ACCEPT
> >>> iptables -A SERVICES -p TCP -s 172.22.99.0/24 --dport 53 -j ACCEPT
> >>> iptables -A SERVICES -p UDP -s 172.22.99.0/24 --dport 53 -j ACCEPT
> >>> iptables -A SERVICES -p TCP -s localhost --dport 53 -j ACCEPT
> >>> iptables -A SERVICES -p UDP -s localhost --dport 53 -j ACCEPT
> >>>
> >>> # Input Chain
> >>> iptables -P INPUT ACCEPT
> >>> iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
> >>> iptables -A INPUT -j SERVICES
> >>> iptables -P INPUT DROP
> >>>
> >>> ## IPv6
> >>> # NAT Routing
> >>> # Services Chain
> >>> ip6tables --flush
> >>>
> >>> # Input Chain
> >>> ip6tables -P INPUT ACCEPT
> >>> ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
> >>> ip6tables -P INPUT DROP
> >>>
> >>> ## Save Ruleset
> >>> iptables-save > /etc/iptables.rules
> >>> ip6tables-save > /etc/ip6tables.rules
> >>>
> >>> ###########################
> >>>
> >>> The client I am using is the OS X built in IKEv1 (aka Cisco IPSec) client and is working well for the private segment (172.21.0.0/16). It’s getting to 172.23.0.0/16 that is the problem.
> >>>
> >>> Thanks for the help!
> >>>
> >>> Tim
> >>>
> >>>
> >>>> On Dec 29, 2014, at 12:12 PM, Noel Kuntze <noel at familie-kuntze.de> wrote:
> >>>>
> >>>>
> >>> Hello Tim,
> >>>
> >>> Please show us your ipsec.conf and tell us what client you are using.
> >>> We will then be able to help you without writing lots of unecessary text.
> >>>
> >>> Mit freundlichen Grüßen/Regards,
> >>> Noel Kuntze
> >>>
> >>> GPG Key ID: 0x63EC6658
> >>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
> >>>
> >>> Am 29.12.2014 um 17:02 schrieb Tim Soderstrom:
> >>>>>> I have a VPN server which handles both a client/server and a site-to-site and have been trying to figure out how to get the client/server to see the network across the site to site. On the client connections, I include the remote IP range in ‘leftsubnet’ but I suspect their is either an ordering problem or maybe an iptables issue. StrongSWAN does add a forward from my client range to the remote range though, so I’m not sure what I’m missing. The site to site itself works like a champ so it’s just getting the client/server VPN to see it.
> >>>>>>
> >>>>>> Is there any documentation on this, or any thoughts or suggestions?
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Tim
> >>>>>> _______________________________________________
> >>>>>> Users mailing list
> >>>>>> Users at lists.strongswan.org
> >>>>>> https://lists.strongswan.org/mailman/listinfo/users
> >>>
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users at lists.strongswan.org
> >>>> https://lists.strongswan.org/mailman/listinfo/users
> >>>
>
>>
>>
>

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

iQIcBAEBCAAGBQJUoapWAAoJEDg5KY9j7GZYbjYP/jkeFg+wiezqtDA+pi2PSGLC
L5A5ex3QhPHpyvYRIaZ3yqNToLrmUZX1UO0xSKDOJ5dXbsLBnEIiNGA0d5/72xBP
zHou3g7wPO4YeQ4JsDQHiBDh9WyRAA86+nMIzhB7AW71YKx4YPYsxNjt5Wkxz7Fd
cOkHmbvC88d4A3besgdRWJOkFpebd+2TTSwZg5kdTu82eUe95/rgsKs1StHJlRp4
oMuMRko7bWQ6xkCbFdu60bwESdE3Lg6rVKtIRqzcy4VB3oGROtif2VeKkG3POo04
BnSrfNkOPXzUYkRyY063jukjw+batKIZqjzGAnBdaNF5e3nTlvL5IyFtoHxNowhu
U0gVcKQJ6XoXYT3Qt95bIWrp1BfY8pV+Juassf9Jhe5WzOlHE0y8XSav9K4pJHWC
fAQifASc/BO3aP3cAzgzWEzR9lmd2aePv0gargNvb4OJEOCx170niZiOVlwcM/tZ
cN+7bbmvL0ba/QoidpwkKty5d0ny8T8IB3lzK3a592TxyxBc0J0tJ+MtgBI7jNwk
OxLm//HsNU2ge70XBLov/YTBTbMHuKASvLffI70YGUDWCvj+Kx1Sd0aJifz9nr6f
Hp+iQ56HS+/i3cQRWnc0vf7jcS1YCLUFKLunoJG064oDFecxb3SUyll3BwfTRrIH
aQ9CAPbOzJvxjpCuCvuV
=VopF
-----END PGP SIGNATURE-----



More information about the Users mailing list