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

Greg Scott GregScott at InfraSupportEtc.com
Sat Sep 16 01:00:57 EDT 2006


One of the suggestions offered in this list to fix MTU issues turns out
not to work so well.  IPSEC adds some overhead to packets and this means
the payload must be a little bit smaller than normal.  So the route
through the IPSEC tunnel needs a slightly smaller MTU.  

Assuming a tunnel from the local net to 10.0.0.0/8, one suggestion was
to try this:

/sbin/ip route change 10.0.0.0/8 dev eth0 mtu 1470

Or some number smaller than 1500.  

So I tried it.  Results were ugly.  Whenever I change the MTU - and this
seems to happen no matter what value I set it to, it seems to mess up my
leftsourceid in the conn definition for that tunnel.  This, in turn,
messes up dhcp relay, which in turn, eventually shuts everyone down.
Restarting IPSEC fixes it up.  

Raw evidence with some annotations below.  Hopefully the emailer won't
run all the text lines together.  I will post the conn definitions and
some other comments below that.  

First, the routes before:

[root at roseville-fw ipsec.d]# /sbin/ip route show
aa.bb.cc.32/29 dev eth0  proto kernel  scope link  src aa.bb.cc.33 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.2 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.187 
10.15.1.0/24 dev eth1  scope link 
169.254.0.0/16 dev eth2  scope link 
10.0.0.0/8 dev eth0  scope link  src 10.15.1.1 
default via aa.bb.cc.38 dev eth0 
[root at roseville-fw ipsec.d]# 


Pinging a host across the tunnel works, right from the router.  (The
conn definition has a leftsourceid line.)


[root at roseville-fw ipsec.d]# 
[root at roseville-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=65.3 ms
64 bytes from 10.13.1.22: icmp_seq=2 ttl=127 time=65.4 ms
64 bytes from 10.13.1.22: icmp_seq=3 ttl=127 time=65.2 ms

--- 10.13.1.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 65.273/65.348/65.441/0.069 ms


Now changing the MTU on the tunnel route


[root at roseville-fw ipsec.d]# /sbin/ip route change 10.0.0.0/8 dev eth0
mtu 1470


The routes after:

[root at roseville-fw ipsec.d]# /sbin/ip route show
aa.bb.cc.32/29 dev eth0  proto kernel  scope link  src aa.bb.cc.33 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.2 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.187 
10.15.1.0/24 dev eth1  scope link 
169.254.0.0/16 dev eth2  scope link 
10.0.0.0/8 dev eth0  scope link  mtu 1470
default via aa.bb.cc.38 dev eth0 
[root at roseville-fw ipsec.d]# 

And trying the ping now fails...

[root at roseville-fw ipsec.d]# ping 10.13.1.22
PING 10.13.1.22 (10.13.1.22) 56(84) bytes of data.
>From aa.bb.cc.33 icmp_seq=1 Destination Host Unreachable
>From aa.bb.cc.33 icmp_seq=2 Destination Host Unreachable
>From aa.bb.cc.33 icmp_seq=3 Destination Host Unreachable

--- 10.13.1.22 ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time
5019ms
, pipe 3

But this ping from the internal interface works...
(The conn definition is supposed to include the internal interface.)


[root at roseville-fw ipsec.d]# 
[root at roseville-fw ipsec.d]# ping 10.13.1.22 -I 10.15.1.1
PING 10.13.1.22 (10.13.1.22) from 10.15.1.1 : 56(84) bytes of data.
64 bytes from 10.13.1.22: icmp_seq=1 ttl=127 time=65.3 ms
64 bytes from 10.13.1.22: icmp_seq=2 ttl=127 time=66.1 ms
64 bytes from 10.13.1.22: icmp_seq=3 ttl=127 time=65.0 ms
64 bytes from 10.13.1.22: icmp_seq=4 ttl=127 time=65.0 ms

--- 10.13.1.22 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 65.003/65.392/66.182/0.543 ms


Restart IPSEC and we're back to normal again.  


[root at roseville-fw ipsec.d]# /etc/rc.d/init.d/ipsec restart
Shutting down IPsec:  Stopping Openswan IPsec...
                                                           [  OK  ]
Starting IPsec:  Starting Openswan IPsec 2.4.4...
insmod /lib/modules/2.6.17.2fw21/kernel/net/key/af_key.ko 
insmod /lib/modules/2.6.17.2fw21/kernel/net/ipv4/xfrm4_tunnel.ko 
insmod /lib/modules/2.6.17.2fw21/kernel/net/xfrm/xfrm_user.ko 
                                                           [  OK  ]
[root at roseville-fw ipsec.d]# 
[root at roseville-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=65.6 ms
64 bytes from 10.13.1.22: icmp_seq=2 ttl=127 time=65.1 ms
64 bytes from 10.13.1.22: icmp_seq=3 ttl=127 time=65.4 ms

--- 10.13.1.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 65.144/65.391/65.616/0.193 ms
[root at roseville-fw ipsec.d]# 


And the routes are back to the way they were:

[root at roseville-fw ipsec.d]# /sbin/ip route show
aa.bb.cc.32/29 dev eth0  proto kernel  scope link  src aa.bb.cc.33 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.2 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.187 
10.15.1.0/24 dev eth1  scope link 
169.254.0.0/16 dev eth2  scope link 
10.0.0.0/8 dev eth0  scope link  src 10.15.1.1 
default via aa.bb.cc.38 dev eth0 
[root at roseville-fw ipsec.d]# 


Here are my conn definitions as they are right now.  I have my own
unique midwest USA memory aid for remembering right from left:


[root at roseville-fw ipsec.d]# more roseville-ipsec.conf
# /etc/ipsec.d/roseville.conf - IPsec configuration file for Roseville.
# The HOME office in Lakeville is always on the right.  ("Make yerself
RIGHT at home!",
# while the other branch sites have LEFT home.)
#
# Openswan bundled with fc5 - see thee include directive from
/etc/ipsec.conf.
#
#       Here are some useful commands:
#
#       /usr/sbin/ipsec showhostkey --file /etc/ipsec.d/hostkey.secrets
--right
#       /usr/sbin/ipsec showhostkey --file /etc/ipsec.d/hostkey.secrets
--left
#
#       /usr/sbin/ipsec showhostkey --file /etc/ipsec.d/hostkey.secrets
--right > rightkey.txt
#       Show this host's public key in a format suitable to insert into 
#       ipsec.conf.  This host can be either the left or right key.
#
#       /usr/sbin/ipsec auto --down london-farout
#       Brings down the tunnel named london-farout
#
#       /usr/sbin/ipsec auto --up london-farout
#       Brings up the tunnel named london-farount
#
#       /usr/local/sbin/ipsec look
#       To observe all kinds of stuff about the IPSEC tunnels
#
#       /usr/local/sbin/ipsec showhostkey > junk.tmp
#       Generates a DNS key record into the file junk.tmp for later 
#       insertion into a DNS zone file
#
#       These were some equivalent commands under prior versions of Open
S/WAN
#       /usr/sbin/ipsec showhostkey --left
#       /usr/sbin/ipsec showhostkey --right
#       /usr/sbin/ipsec showhostkey --left > junk.tmp
#

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration

conn Roseville-Everywhere
        # Identical to Roseville-Lakeville except for the rightsubnet.
        type=tunnel
        #
        # Left security gateway, subnet behind it, next hop toward
right.
        #
        also=Roseville
        #
        # Right security gateway, subnet behind it, next hop toward
left.
        #
        also=Lakeville
        rightsubnet=10.0.0.0/8
        auto=start

###     leftupdown=/etc/ipsec.d/roseville-updown.sh

#
# Just pass local packets to the kernel without ipsec
#

##conn pass-localstuff
##      left=10.15.1.1
##      leftsubnet=10.15.1.0/24
##      right=0.0.0.0
##      rightsubnet=10.15.1.0/24
##      auto=route
##      authby=never
##      type=passthrough

include /etc/ipsec.d/sites.conf
[root at roseville-fw ipsec.d]# 
[root at roseville-fw ipsec.d]# more sites.conf
# /etc/ipsec.d/sites.conf - IPsec configuration file describing each
site.
# The HOME office in Lakeville is always on the right.  ("Make yerself
RIGHT at home!",
# while the other branch sites have LEFT home.)
#
# Openswan bundled with fc5 - see thee include directive from
/etc/ipsec.conf.
#
#       Here are some useful commands:
#
#       /usr/sbin/ipsec showhostkey --file /etc/ipsec.d/hostkey.secrets
--right
#       /usr/sbin/ipsec showhostkey --file /etc/ipsec.d/hostkey.secrets
--left
#
#       /usr/sbin/ipsec showhostkey --file /etc/ipsec.d/hostkey.secrets
--right > rightkey.txt
#       Show this host's public key in a format suitable to insert into 
#       ipsec.conf.  This host can be either the left or right key.
#
#       /usr/sbin/ipsec auto --down london-farout
#       Brings down the tunnel named london-farout
#
#       /usr/sbin/ipsec auto --up london-farout
#       Brings up the tunnel named london-farount
#
#       /usr/local/sbin/ipsec look
#       To observe all kinds of stuff about the IPSEC tunnels
#
#       /usr/local/sbin/ipsec showhostkey > junk.tmp
#       Generates a DNS key record into the file junk.tmp for later 
#       insertion into a DNS zone file
#
#       These were some equivalent commands under prior versions of Open
S/WAN
#       /usr/sbin/ipsec showhostkey --left
#       /usr/sbin/ipsec showhostkey --right
#       /usr/sbin/ipsec showhostkey --left > junk.tmp
#

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration


conn Roseville
        left=aa.bb.cc.33
        leftnexthop=aa.bb.cc.38
        leftsubnet=10.15.1.0/24
        leftsourceip=10.15.1.1
        leftid=@roseville.local
        # RSA 2192 bits   roseville-fw   Thu Jul 20 18:47:26 2006
        leftrsasigkey=0sAQPHZAiDYgm...

conn Lakeville
        right=pp.qq.rr.154
        rightnexthop=pp.qq.rr.153
        rightsourceip=10.13.1.1
        rightid=@lakeville.local
        # RSA 2192 bits   lakeville-fw   Wed Jul 19 21:09:32 2006
        rightrsasigkey=0sAQNb9diwRKMmp5d4CHzj...
        #
[root at roseville-fw ipsec.d]# 
[root at roseville-fw ipsec.d]# 
[root at roseville-fw ipsec.d]# 
[root at roseville-fw ipsec.d]# 

I saw a mention in the archives for a way to set the MTU in a conn
definition.  I think I will try that next.  If that doesn't work, I
guess I will just have to set up lots of tunnels to each specific subnet
and give up on consolidating tunnels to places with more than one
subnet.  

Thanks for wading through all of this with me.

- Greg Scott


More information about the Users mailing list