[Openswan Users] overridemtu on U2.1.4/K2.6.7 (native) not working?

[jerry]

dear list,
I encountered strange behavior while testing my new setup.
When tcp-packets going encrypted reached some size, say 1369 bytes or more,
they are eaten by my ISP and do never arrive at my roadwarrior.
Because smaller packets works great I suspected fragmentation
issue and I tried to lower the mtu value by explicitly setting overridemtu.
But this doesn't help in any way. So I tcpdumped and discovered
that nothing has changed in the size of outgoing esp-packets ->still at 1480 in size.
I reduced the mtu of the ETH1 (inet-side) and restarted openswan.
Thats it! The mtu/mss of ESP's was shorter and I can surf and ssh and all other things!
;-)

the bad news is that by changing the mtu of the eth-interface all traffic
is slow down :-(


my setup follows:

000 interface eth0/eth0 192.168.0.143
000 interface lo/lo 127.0.0.1
000 interface eth1/eth1 10.0.0.2
000 %myid = C=DE, ST=Hamburg, O=xyz.de, OU=NetworkSecurity, CN=hostxyz.ath.cx, E=jz at xyz.de
000 debug none
000
000 "road_office": 192.168.0.0/24===10.0.0.2[C=DE, ST=Hamburg, O=mycompany.de, OU=NetworkSecurity, CN=mycompany.ath.cx, E=jz at mycompany.de,S=C]---10.0.0.1...%virtual[S=C]===?; unrouted; eroute owner: #0
000 "road_office":   CAs: 'C=DE, ST=Hamburg, L=OfficeHH, O=mycompany.de, OU=NetworkSecurity, CN=mycompanyRootCA, E=jz at mycompany.de'...'%any'
000 "road_office":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1
000 "road_office":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; prio: 24,32; interface: eth1;
000 "road_office":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "road_office"[8]: 192.168.0.0/24===10.0.0.2[C=DE, ST=Hamburg, O=mycompany.de, OU=NetworkSecurity, CN=mycompany.ath.cx, E=jz at mycompany.de,S=C]---10.0.0.1...62.104.95.27[C=DE, ST=Hamburg, L=OfficeHH, O=mycompany.de, OU=NetworkSecurity, CN=Client, E=jz at mycompany.de,S=C]; erouted; eroute owner: #8
000 "road_office"[8]:   CAs: 'C=DE, ST=Hamburg, L=OfficeHH, O=mycompany.de, OU=NetworkSecurity, CN=mycompanyRootCA, E=jz at mycompany.de'...'%any'
000 "road_office"[8]:   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1
000 "road_office"[8]:   policy: RSASIG+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; prio: 24,32; interface: eth1;
000 "road_office"[8]:   newest ISAKMP SA: #0; newest IPsec SA: #8;
000
000 #8: "road_office"[8] 62.104.95.27 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1345s; newest IPSEC; eroute owner
000 #8: "road_office"[8] 62.104.95.27 esp.b2a50930 at 62.104.95.27 esp.b5e775d7 at 10.0.0.2 tun.0 at 62.104.95.27 tun.0 at 10.0.0.2
000

The openswan router/firewall (192.168.0.143/10.0.0.2) is behind an alcatel-sdsl-router,
which simply forwards all new incoming traffic to 10.0.0.2.

The roadwarrior connects to internet using an adsl-modem/dynip.

smaller packets (1359 bytes) are transmitted well!

62.104.95.27.3337 > 192.168.0.43.http: S 320981092:320981092(0) win 65044 <mss 1414,nop,nop,sackOK> (DF)
192.168.0.43.http > 62.104.95.27.3337: S 145490734:145490734(0) ack 320981093 win 5840 <mss 1460,nop,nop,sackOK> (DF)
62.104.95.27.3337 > 192.168.0.43.http: . ack 1 win 65044 (DF)
62.104.95.27.3337 > 192.168.0.43.http: P 1:272(271) ack 1 win 65044 (DF)
192.168.0.43.http > 62.104.95.27.3337: . ack 272 win 6432 (DF)
192.168.0.43.http > 62.104.95.27.3337: P 1:1359(1358) ack 272 win 6432 (DF)
192.168.0.43.http > 62.104.95.27.3337: F 1359:1359(0) ack 272 win 6432 (DF)
62.104.95.27.3337 > 192.168.0.43.http: . ack 1360 win 63686 (DF)
62.104.95.27.3337 > 192.168.0.43.http: F 272:272(0) ack 1360 win 63686 (DF)
192.168.0.43.http > 62.104.95.27.3337: . ack 273 win 6432 (DF)

both ends say:fin->ack (ok)

bigger packets (1369 bytes) are NOT transmitted from inside to outside!

62.104.95.27.3341 > 192.168.0.43.http: S 332136976:332136976(0) win 65044 <mss 1414,nop,nop,sackOK> (DF)
192.168.0.43.http > 62.104.95.27.3341: S 193244950:193244950(0) ack 332136977 win 5840 <mss 1460,nop,nop,sackOK> (DF)
62.104.95.27.3341 > 192.168.0.43.http: . ack 1 win 65044 (DF)
62.104.95.27.3341 > 192.168.0.43.http: P 1:272(271) ack 1 win 65044 (DF)
192.168.0.43.http > 62.104.95.27.3341: . ack 272 win 6432 (DF)
192.168.0.43.http > 62.104.95.27.3341: P 1:1369(1368) ack 272 win 6432 (DF)
192.168.0.43.http > 62.104.95.27.3341: F 1369:1369(0) ack 272 win 6432 (DF)
62.104.95.27.3341 > 192.168.0.43.http: . ack 1 win 65044 <nop,nop,sack sack 1 {1369:1370} > (DF)
192.168.0.43.http > 62.104.95.27.3341: P 1:1369(1368) ack 272 win 6432 (DF)
192.168.0.43.http > 62.104.95.27.3341: P 1:1369(1368) ack 272 win 6432 (DF)
192.168.0.43.http > 62.104.95.27.3341: P 1:1369(1368) ack 272 win 6432 (DF)
62.104.95.27.3341 > 192.168.0.43.http: R 332137248:332137248(0) win 0 (DF)

client doesn't got the big packet and doesn't say fin (nok)

this issue happens only when the roadwarrior accesses hosts in the internal lan,
the other way is ok.

The roadwarrior is xp with this nat patch from ms and uses native ipsec with MM-Tool.
The IPSec gateway is U2.1.4/K2.6.7 compiled on gcc-3.2.2


myarse:~# tracepath 62.104.95.27
 1:  myarse.internal (192.168.0.43)                         0.646ms pmtu 1500
  1:  ns.internal (192.168.0.143)                            0.675ms
   2:  ns.internal (192.168.0.143)                          asymm  1   0.650ms pmtu 1444
    3:  no reply
     4:  no reply