[Openswan Users] Changing MTU on a route seems to mess upleftsourceid in a conn definition

[Greg Scott]

Yes!!!!!!!!!!!!

Thank you thank you thank you again!!!  That seemed to do the trick!
Here's a before (messed up) and after (fixed) from Woodbury, another
site set up the same way.

And yup, I meant leftsourceip, not id.  It's been a long day...

[root at Woodbury-fw ipsec.d]# ping 10.13.1.22
PING 10.13.1.22 (10.13.1.22) 56(84) bytes of data.

--- 10.13.1.22 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms

[root at Woodbury-fw ipsec.d]# /sbin/ip route show
dd.ee.ff.136/29 dev eth0  proto kernel  scope link  src dd.ee.ff.138 
10.17.1.0/24 dev eth1  proto kernel  scope link  src 10.17.1.1 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.177 
169.254.0.0/16 dev eth2  scope link 
10.0.0.0/8 dev eth0  scope link  mtu 1200
default via dd.ee.ff.137 dev eth0 
[root at Woodbury-fw ipsec.d]# /sbin/ip route change 10.0.0.0/8 dev eth0
src 10.17.1.1 mtu 1200
[root at Woodbury-fw ipsec.d]# /sbin/ip route show
dd.ee.ff.136/29 dev eth0  proto kernel  scope link  src dd.ee.ff.138 
10.17.1.0/24 dev eth1  proto kernel  scope link  src 10.17.1.1 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.177 
169.254.0.0/16 dev eth2  scope link 
10.0.0.0/8 dev eth0  scope link  src 10.17.1.1  mtu 1200
default via dd.ee.ff.137 dev eth0 
[root at Woodbury-fw ipsec.d]# ping 10.13.1.22
PING 10.13.1.22 (10.13.1.22) 56(84) bytes of data.
64 bytes from 10.13.1.22: icmp_seq=1 ttl=127 time=43.2 ms
64 bytes from 10.13.1.22: icmp_seq=2 ttl=127 time=42.8 ms
64 bytes from 10.13.1.22: icmp_seq=3 ttl=127 time=43.1 ms

--- 10.13.1.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 42.895/43.104/43.295/0.235 ms
[root at Woodbury-fw ipsec.d]# 


- Greg