Hello Noel, thanks for the reply. I think i got it now.
Thanks too for the other two suggestions. Best regards, Michael > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello Michael, > > They're not weird. They tell the host strongSwan is running > on where to route the encapsulated packets for the roadwarriors > to. Also, the routes can be necessary because of the rp filter. > This is default behaviour. > > Your NAT rules don't look good, take a look at ForwardingAndSplitTunneling[1]. > Also, posting output of "iptables -L" is pretty bad. Use iptables-save. Its > format > is much better and it shows all available tables by default. > > [1]https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#Hosts-on-the-Internet > > Mit freundlichen Grüßen/Kind Regards, > Noel Kuntze > > GPG Key ID: 0x63EC6658 > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > > Am 22.07.2015 um 11:28 schrieb Michael Stiller: >> Hi, >> >> i configured a strongswan ipsec gateway to use with ios devices. >> The ipsec connections should terminate on the gateway and the ios devices >> should be able to access the internet. >> >> Everything seems to work but there are strange routing entries in table 220: >> >> ip route list table 220 >> 10.1.0.1 via 172.31.16.1 dev eth0 proto static >> 10.1.0.2 via 172.31.16.1 dev eth0 proto static >> >> This does not make any sense to me, why is this inserted? >> >> 10.1.0.0/24 are the connecting clients and 172.31.16.1 is my default gw: >> >> # ip route list >> default via 172.31.16.1 dev eth0 >> >> The virtual ips 10.1.0.0/24 are assigned using radius framed-ip-address. >> >> Access to the internet works, the devices are masqueraded: >> >> # iptables -L -n -t nat >> 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 >> MASQUERADE all -- 10.0.0.0/8 0.0.0.0/0 >> >> This is my ipsec.conf: >> >> conn ios >> keyexchange=ikev1 >> authby=xauthrsasig >> xauth=server >> type=tunnel >> esp=aes128gcm8-sha1 >> ike=aes128gcm8-sha1-modp1024 >> leftsubnet=0.0.0.0/0 >> leftcert=serverCert.pem >> lefthostaccess=yes >> right=%any >> rightsourceip=%radius >> rightcert=clientCert.pem >> dpdaction=clear >> auto=add >> >> Relevant charon.conf: >> >> charon { >> cisco_unity = yes >> dns1 = 172.31.20.201 >> install_virtual_ip = yes >> install_virtual_ip_on = eth0 >> crypto_test { >> } >> host_resolver { >> } >> leak_detective { >> } >> processor { >> priority_threads { >> } >> } >> tls { >> } >> x509 { >> } >> } >> >> # ipsec statusall #redacted >> Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-57-generic, >> x86_64): >> uptime: 25 minutes, since Jul 22 08:57:11 2015 >> malloc: sbrk 2433024, mmap 0, used 412800, free 2020224 >> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, >> scheduled: 15 >> loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 rdrand 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-radius addrblock >> Listening IP addresses: >> 172.31.20.201 >> Connections: >> ios: %any...%any IKEv1, dpddelay=30s >> ... >> ios: remote: uses XAuth authentication: any >> ios: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear >> Security Associations (1 up, 0 connecting): >> ios[4]: ESTABLISHED 1 second ago, 172.31.20.201 ... >> ios[4]: Remote XAuth identity: ms_be >> ios[4]: IKEv1 SPIs: c33574XXXXXXX 119a824XXXXXXX, public key >> reauthentication in 2 hours >> ios[4]: IKE proposal: >> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536 >> ios{4}: INSTALLED, TUNNEL, ESP in UDP SPIs: cXXXXXXXXX 0XXXXXXXXX >> ios{4}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in >> 43 minutes >> ios{4}: 0.0.0.0/0 === 10.1.0.1/32 >> >> # ip xfrm policy >> src 10.1.0.1/32 dst 0.0.0.0/0 >> dir fwd priority 1923 >> tmpl src 91.x.x.x dst 172.31.20.201 >> proto esp reqid 4 mode tunnel >> src 10.1.0.1/32 dst 0.0.0.0/0 >> dir in priority 1923 >> tmpl src 91.x.x.x dst 172.31.20.201 >> proto esp reqid 4 mode tunnel >> src 0.0.0.0/0 dst 10.1.0.1/32 >> dir out priority 1923 >> tmpl src 172.31.20.201 dst 91.x.x.x >> proto esp reqid 4 mode tunnel >> >> # ip xfrm state >> src 172.31.20.201 dst 91.x.x.x >> proto esp spi 0x0XXXXXXX reqid 4 mode tunnel >> replay-window 32 flag af-unspec >> auth-trunc hmac(sha1) somehash 96 >> enc cbc(aes) anotherhash >> encap type espinudp sport 4500 dport 64378 addr 0.0.0.0 >> src 91.x.x.x dst 172.31.20.201 >> proto esp spi 0xcXXXXXXX reqid 4 mode tunnel >> replay-window 32 flag af-unspec >> auth-trunc hmac(sha1) somehash 96 >> enc cbc(aes) anotherhash >> encap type espinudp sport 64378 dport 4500 addr 0.0.0.0 >> >> The question is: >> >> Is there some obvious misconfiguration which causes the routes in table 220 >> to appear. >> It looks like the strange routes do no harm, as everything works as expected >> so far or will they? >> Any general hints for this setup? >> >> Thanks and best regards, >> >> Michael >> >> >> >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.strongswan.org/mailman/listinfo/users > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJVr2ZFAAoJEDg5KY9j7GZYnJ4P/1h622frX8VdO8vl+1JlAjq+ > U2fS9XdiVJUvAONhSGiPnbefVj/jFF1cJNkvbPUMTooz1gNaiV5xb8kEXa/qTT+G > j79Ne5pOgca+Kz8flCCzcT2rkmSzCl1uGXKS876ki0xVUQ4L8x3SqkL3TTgKZv3M > r5iApvJhzSWH8APG1dkZ7wulXmyImiRnEiao1mRWcLxqI3x3lTS/jrL6NQVA2Ly5 > 7TpWhHSazYxwJSity2QQbKsCsshQD4JlOFOIHbtdtFXmYaNsTs7PUVYYW+TIk9LY > jqtLPw43+IG/IkF1Klac0NbzxhQ1KuHSsBdwZYtUX4Qz1oVZT0pLXAAB+bGw7H3z > DOU37wPQ4hPqkDI2d9zlwvMFwRHUwWAGbG4cZNHzVcuTXwRJfFXQ+jdZ8+e+kz0S > nczWy1WGZdQ9LUq/GioL3iM1Pg8oYN9Z+RZbVz9idd/lBXz+RLRsZqTZy8alHAxU > LpQFHK9GNE9NnEIBkA02PsbqBoJlf3uQq1rLi7m3Toy7rEj06dhfChQzbS9kjmkW > 05DD4GBs3o/z5ZvN+MuPkMXbLwuz8UiH+LhW8MqUoBw9NO7GI9vjENK4a4Vfds7J > 5y0j8gCVcQa2vpOY/UG9Isc8rxW0NcSpb/SSIdiiJsbZKfycv96f8LSEiP5y4rJW > bYAoPwULuBeHJE9NN2t9 > =7lyz > -----END PGP SIGNATURE----- > > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
