Fellow StrongSwan users, I run a gateway with StrongSwan 4.5.3 to connect a bunch of mobile users and home offices to a corporate net.
The mobile workforce uses the built-in capabilities of XP (L2TP over IPsec) and/or Win7 (IKEv2). Their PPP interfaces are in 172.18.0.0/16 range. I have been asked to offer Internet access from the home office, across the IPsec tunnel (inbound), and via the corporate firewall (outbound). (call it political routing, if you like) We had something like this with a previous gateway with FreeSwan on it, so I tried again: # mark traffic from the mobile workforce iptables -t mangle -A PREROUTING -s 172.18.0.0/16 -j MARK --set-mark 2 # use another routing table for marked traffic ip rule add pref 880 fwmark 2 lookup inbound # route towards corporate core ip route add default via 172.21.59.2 dev eth0 table inbound (the gateway's "normal" default route remains in table "main") At first sight, this worked as expected. But, shortly after, I got complaints from IKEv2 users about apparently random disconnects. Research in the log reveals: Aug 27 20:53:49 vpn-gateway-4 pppd[18772]: pppd 2.4.4 started by root, uid 0 Aug 27 20:53:49 vpn-gateway-4 pppd[18772]: Using interface ppp10 Aug 27 20:53:49 vpn-gateway-4 pppd[18772]: Connect: ppp10 <--> /dev/pts/10 Aug 27 20:53:51 vpn-gateway-4 pluto[918]: 172.18.4.1 appeared on ppp10 Aug 27 20:53:51 vpn-gateway-4 pluto[918]: 172.18.4.1 disappeared from ppp10 Aug 27 20:53:51 vpn-gateway-4 charon: 01[KNL] 172.18.4.1 appeared on ppp10 Aug 27 20:53:51 vpn-gateway-4 charon: 01[KNL] 172.18.4.1 disappeared from ppp10 Aug 27 20:53:51 vpn-gateway-4 charon: 01[KNL] 172.18.4.1 appeared on ppp10 Aug 27 20:53:51 vpn-gateway-4 charon: 01[KNL] interface ppp10 activated Aug 27 20:53:51 vpn-gateway-4 pluto[918]: 172.18.4.1 appeared on ppp10 Aug 27 20:53:51 vpn-gateway-4 pluto[918]: interface ppp10 activated Aug 27 20:53:51 vpn-gateway-4 pppd[18772]: local IP address 172.18.4.1 Aug 27 20:53:51 vpn-gateway-4 pppd[18772]: remote IP address 172.18.4.156 Aug 27 20:53:51 vpn-gateway-4 pppd[18772]: Script /etc/ppp/ip-up finished (pid 18774), status = 0x0 The above is the result of a L2TP-over-IPsec (IKEv1) connection coming up. Aug 27 20:53:51 vpn-gateway-4 charon: 13[IKE] old path is not available anymore, try to find another Aug 27 20:53:51 vpn-gateway-4 charon: 13[IKE] sending address list update using MOBIKE, implicitly requesting an address change Aug 27 20:53:51 vpn-gateway-4 charon: 13[ENC] generating INFORMATIONAL request 0 [ ] Aug 27 20:53:51 vpn-gateway-4 charon: 13[IKE] checking original path 172.21.59.8[4500] - 188.61.38.247[53975] Aug 27 20:53:51 vpn-gateway-4 charon: 13[NET] sending packet: from 172.21.59.8[4500] to 188.61.38.247[53975] Aug 27 20:53:54 vpn-gateway-4 charon: 14[IKE] path probing attempt 1 Aug 27 20:53:54 vpn-gateway-4 charon: 14[IKE] checking original path 172.21.59.8[4500] - 188.61.38.247[53975] Aug 27 20:53:54 vpn-gateway-4 charon: 14[NET] sending packet: from 172.21.59.8[4500] to 188.61.38.247[53975] Aug 27 20:53:56 vpn-gateway-4 charon: 06[IKE] path probing attempt 2 Aug 27 20:53:56 vpn-gateway-4 charon: 06[IKE] checking original path 172.21.59.8[4500] - 188.61.38.247[53975] Aug 27 20:53:56 vpn-gateway-4 charon: 06[NET] sending packet: from 172.21.59.8[4500] to 188.61.38.247[53975] ... Aug 27 20:54:16 vpn-gateway-4 charon: 14[IKE] path probing attempt 10 Aug 27 20:54:16 vpn-gateway-4 charon: 14[IKE] checking original path 172.21.59.8[4500] - 188.61.38.247[53975] Aug 27 20:54:16 vpn-gateway-4 charon: 14[NET] sending packet: from 172.21.59.8[4500] to 188.61.38.247[53975] Aug 27 20:54:19 vpn-gateway-4 charon: 06[IKE] giving up after 10 path probings Aug 27 20:54:19 vpn-gateway-4 charon: 06[KNL] received netlink error: No such process (3) Aug 27 20:54:19 vpn-gateway-4 charon: 06[KNL] unable to install source route for %any Aug 27 20:54:19 vpn-gateway-4 charon: 06[CFG] sending DHCP RELEASE for 172.18.6.251 to 192.0.2.103 In other words: each time an L2TP-over-IPsec connection (XP) goes up or down, IKEv2 connections get in trouble because caron seems to get confused about the two "default routes" (although in separate tables). It helps to replace "the real default-route of the gateway" by ip route add 128.0.0.0/1 via 194.209.6.1 ip route add 0.0.0.0/1 via 194.209.6.1 Therefore, I don't have a urgent problem :-) But what's going on here might be of interest for the maintainers of charon. And by the way, thanks for StrongSwan. It serves us well. Best regards, Walter _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
