[strongSwan] Strange routing table 220 entries
Noel Kuntze
noel at familie-kuntze.de
Wed Jul 22 11:45:43 CEST 2015
-----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