[strongSwan] Strange routing table 220 entries

[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