Yep plugin is loaded. ######### loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity eap-md5 eap-tls xauth-generic xauth-noauth addrblock unity #########
You lost me a bit about how I can check the negotiated traffic selector? That should be part of the logging information, yeah? I looked on the StrongSWAN wiki for some examples to check and I don’t actually see any selectors mentioned in syslog, although they’re working independently since client/server VPN works, as does the site-to-site (I’m just not able to get to the remote private network - the 172.23 - via the client/server, only the local one - 172.21) I had a thought - maybe it’s a SNAT issue? Since the client VPN connections seem to be NAT’d do the VPN server’s private IP on the local private network, I’m guessing SNAT is being attempted on the remote side? Is SNAT fully required in this case since we’re dealing with all private networks? It would actually be more beneficial for me to use see client VPN range on other private servers anyway since I’m providing static IP addresses per user on the VPN and can do filtering if needed. In fact I would have attempted to turn it off if I knew how ;) but just getting OS X to play nice with the StrongSWAN was worth of celebration (thanks Apple….*sigh*) though now it does work like a champ. Tim > On Dec 29, 2014, at 1:24 PM, Noel Kuntze <[email protected]> wrote: > > > -----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@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@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@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 <[email protected]> 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 >>>>> [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 > > 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----- > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
