[strongSwan] Strange routing table 220 entries
Michael Stiller
ms at 2scale.net
Wed Jul 22 12:12:54 CEST 2015
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
>> Users at lists.strongswan.org
>> 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-----
>
>
More information about the Users
mailing list