-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 > [email protected] > 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 <[email protected]> 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 > >>> [email protected] > >>> https://lists.strongswan.org/mailman/listinfo/users > >> >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.strongswan.org/mailman/listinfo/users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUoaJkAAoJEDg5KY9j7GZYS5wP/RqTP3OibjDJltrGBgC5zjE+ jpXrnn2FCLrDKH/f4/jMBfA6MHjghx0MHve2vJZi1DW06aN0xs0l2QOqPOEMQRcE pHzsuq003aK3yKrDOA5/65BXLmoUoSWLUcj8+1mXPIIoJ0R56X0TqDT+9ubXOtRq uyFfmdkxe5xQlbDKoF7+y2e4kq8Ng4oizvXpaZSxj4uvpUEuBiYyBdL8L/G+ucaB 11vmWCf117jncy4iLODol/QlVT2pkOLfMteB9UXuveZxbWZs+az/7QAMNh0Mrm8C wIOu/UHI321W0voaDV08v6OdYF6irodzBWtyGlcTwFvc2ZOOKOkAgNTOQ1EJXfQq 6wLPkTPItLt0m5+IO9FFy6sLkiuBkba9/6Fnx9P3WkjDVHZCpXdzf1pdpExVokY3 lTCi/kVY+uqrq3JEYM7nXnAfZUcL7euCiznn5N9IO8qk5udMNBrTL04EicFWIGOj nfkv/Y2cXb7KQgNnWu4Bmb0pl0KCgwTG8SXkBV3nldKEsqKWfveC+14UEiP4HRW7 cA0FjRWPyfPyQMB4lCNWcCOkXOMJXutzeOo0TmTbrQiCkY5RYqoy4DahTwjht/nX lBOeY9q+xCr8Z3kLJGC046pqvE7jS7Qpw125akqNxyXkH2XG6A6lmdHJjaUccRLp XK59Ew3Hrf42oiSkzxnk =BX+6 -----END PGP SIGNATURE----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
