'[strongSwan] NAT-T and corresponding MTU - difficulties'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    [strongSwan] NAT-T  and corresponding MTU - difficulties
From:       bernhard.thoni () t-online ! de (bernhard ! thoni () t-online ! de)
Date:       2004-12-12 16:14:26
Message-ID: 1CdVQK-0qWcD20 () filter08 ! bbul ! t-online ! de
[Download RAW message or body]

hi ipsec-folks...


Following scenario

    WIN_XP_SP2-Client (native l2tp/ipsec implementation with x.509v3-certs
             I                 path-mtu-discovery activated via drtcp.exe)
             I
     WLAN-DSL-Router (in my case DLINK 624+, does nat, 
             I          NO ipsec-passthrough activated)
             I
             I
          INTERNET  
             I
             I
             I
    VPN-Gateway (Company,Strongswan 2.2.2,Transport-Mode enabled,does nat)
             I
             I
      Company Servers



Amendment:

* Xp_sp2-client has the following patch applied (found on jacco?s site):
http://www.lanarchitect.net/Articles/FixSP2VPN/

* WLAN-router has latest firmware applied

* Inet is reached via MediaWays  (prefer MTU of 1454 on the WLAN router; 
tried with pings from my xp-client: 
ping ?f ?l 1426 www.heisec.de worked + payload of 28

* companies vpn-gateway is connected to inet via 2mbit WLAN connection 
(ethernetframe 1500);   vanilla-kernel 2.4.28 + strongswn 2.2.2 with 
I_WANT_TRANSPORT_MODE_ALTHOUGH_IT_IS_INSECURE

* udp-ports 500 + 4500 on both gateway devices are allowed (firewall)



problem:

ipsec connection (+ following l2tp connection gets established (in my eyes
correctly... i snipped rest of l2tp-log)

Dec 12 15:15:03 lx01-gw01-kmp pluto[11063]: packet from 217.186.85.9:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Dec 12 15:15:03 lx01-gw01-kmp pluto[11063]: packet from 217.186.85.9:500:
ignoring Vendor ID payload [FRAGMENTATION]
Dec 12 15:15:03 lx01-gw01-kmp pluto[11063]: packet from 217.186.85.9:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Dec 12 15:15:03 lx01-gw01-kmp pluto[11063]: packet from 217.186.85.9:500:
ignoring Vendor ID payload [26244d38eddb61b3172a36e3d0cfb819]
Dec 12 15:15:03 lx01-gw01-kmp pluto[11063]: "rw1-new"[3] 217.186.85.9 #7:
responding to Main Mode from unknown peer 217.186.85.9
Dec 12 15:15:03 lx01-gw01-kmp pluto[11063]: "rw1-new"[3] 217.186.85.9 #7:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Dec 12 15:15:04 lx01-gw01-kmp pluto[11063]: "rw1-new"[3] 217.186.85.9 #7:
Peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Bavaria, L=Eggenfelden, O=KMP
PrintTechnik AG, CN=rw-bt.kmp-ag.de, E=bt@kmp-ag.de'
Dec 12 15:15:04 lx01-gw01-kmp pluto[11063]: "rw1-new"[3] 217.186.85.9 #7:
crl update is overdue since Jul 12 18:37:24 UTC 2004
Dec 12 15:15:04 lx01-gw01-kmp pluto[11063]: "l2tp-new"[3] 217.186.85.9 #7:
deleting connection "rw1-new" instance with peer 217.186.85.9
{isakmp=#0/ipsec=#0}
Dec 12 15:15:04 lx01-gw01-kmp pluto[11063]: | NAT-T: new mapping
217.186.85.9:500/62245)
Dec 12 15:15:04 lx01-gw01-kmp pluto[11063]: "l2tp-new"[3] 217.186.85.9:62245
#7: sent MR3, ISAKMP SA established
Dec 12 15:15:04 lx01-gw01-kmp pluto[11063]: "l2tp-new"[3] 217.186.85.9:62245
#8: responding to Quick Mode
Dec 12 15:15:05 lx01-gw01-kmp l2tpd[11780]: ourtid = 27178, entropy_buf =
6a2a
Dec 12 15:15:05 lx01-gw01-kmp pluto[11063]: "l2tp-new"[3] 217.186.85.9:62245
#8: IPsec SA established {ESP=>0x57fa2feb <0x784ab270 NATOA=192.168.0.3}
Dec 12 15:15:06 lx01-gw01-kmp l2tpd[11780]: check_control: control, cid = 0,
Ns = 0, Nr = 0

btw: 2nd line of log (this is MAIN_MODE?) says: FRAGMENTATION.... 
what are the consequences?
do - at this state - already problems have to be expected?

when i do a "ping -f -l 1345" from my roadwarrior to corporate lan-server,
it works....   1346 is to much...

but: opening an application (i.e. outlook2003) which connects to a corporate

imap-server via vpn, i get the following error on the 
linux gateway side , and no data gets through the tunnel to the roadwarrior:

Dec 12 15:22:41 lx01-gw01-kmp pluto[11063]: ERROR: asynchronous network
error report on eth1 for message to 192.168.0.3 port 4500, complainant
217.186.85.9: Message too long [errno 90, origin ICMP type 3 code 4 (not
authenticated)]

only one useful hint on the freeswan-mailinglist led me to the conclusion,
 that is has to do something with MTU on ipsec side with my dlink-router...
(and not on l2tp side, because the error is reported by pluto....)..
http://www.mail-archive.com/users@lists.freeswan.org/msg15367.html

but how is it possible to make a workaround for this problem?
- deal the overridemtu parameter on ipsec.conf? (but voidptr on strongswan
chat suggested this as final try,
  when nothing else works... but which value should it be set here?
- are the certs for the roadwarriors to big? i could create new one with
less information in it...
lx01-gw01-kmp:~ # ls -la /etc/ipsec.d/certs/rw-btcert.pem
-rw-------    1 root     root         5444 Dec  8 20:24
/etc/ipsec.d/certs/rw-btcert.pem


here is another snippet of tcpdump-log on linux-gw

15:53:51.632666 0:2:2d:62:4b:75 0:0:cb:69:1c:43 0800 99: 217.186.85.9.1701 >
217.74.1.134.1701:  l2tp:[L](10732/39870) {IP 49: 192.168.0.120.1044 >
192.168.0.10.143: S 3039686537:3039686537(0) win 16384 <mss 1360,nop,[|tcp]>
(DF) (ttl 64, id 2323, len 48)} (ttl 43, id 2324, len 85)
15:53:51.633193 0:0:cb:69:1c:43 0:0:cb:69:1c:43 0800 95: 217.74.1.134.1701 >
217.186.85.9.1701:  [udp sum ok] l2tp:[L](1/1) {IP 45: 192.168.0.10.143 >
192.168.0.120.1044: S [tcp sum ok] 2532113267:2532113267(0) ack 3039686538
win 5440 <mss 1360> (DF) (ttl 64, id 0, len 44)} (DF) (ttl 64, id 0, len 81)
15:53:51.643929 0:2:2d:62:4b:75 0:0:cb:69:1c:43 0800 99: 217.186.85.9.1701 >
217.74.1.134.1701:  l2tp:[L](10732/39870) {IP 49: 192.168.0.120.1045 >
192.168.0.10.143: S 1587939488:1587939488(0) win 16384 <mss 1360,nop,[|tcp]>
(DF) (ttl 64, id 2325, len 48)} (ttl 43, id 2326, len 85)
15:53:51.644264 0:0:cb:69:1c:43 0:0:cb:69:1c:43 0800 95: 217.74.1.134.1701 >
217.186.85.9.1701:  [udp sum ok] l2tp:[L](1/1) {IP 45: 192.168.0.10.143 >
192.168.0.120.1045: S [tcp sum ok] 2532434258:2532434258(0) ack 1587939489
win 5440 <mss 1360> (DF) (ttl 64, id 0, len 44)} (DF) (ttl 64, id 0, len 81)
15:53:51.768213 0:2:2d:62:4b:75 0:0:cb:69:1c:43 0800 91: 217.186.85.9.1701 >
217.74.1.134.1701:  [udp sum ok] l2tp:[L](10732/39870) {IP 41:
192.168.0.120.1044 > 192.168.0.10.143: . [tcp sum ok] 1:1(0) ack 1 win 17680
(DF) (ttl 64, id 2327, len 40)} (ttl 43, id 2328, len 77)
15:53:51.771744 0:0:cb:69:1c:43 0:0:cb:69:1c:43 0800 203: 217.74.1.134.1701
> 217.186.85.9.1701:  l2tp:[L](1/1) {IP 153: 192.168.0.10.143 >
192.168.0.120.1044: P 1:113(112) ack 1 win 5440 (DF) (ttl 64, id 35335, len
152)} (DF) (ttl 64, id 0, len 189)
15:53:51.804577 0:2:2d:62:4b:75 0:0:cb:69:1c:43 0800 91: 217.186.85.9.1701 >
217.74.1.134.1701:  [udp sum ok] l2tp:[L](10732/39870) {IP 41:
192.168.0.120.1045 > 192.168.0.10.143: . [tcp sum ok] 1:1(0) ack 1 win 17680
(DF) (ttl 64, id 2329, len 40)} (ttl 43, id 2330, len 77)
15:53:51.808465 0:0:cb:69:1c:43 0:0:cb:69:1c:43 0800 203: 217.74.1.134.1701
> 217.186.85.9.1701:  l2tp:[L](1/1) {IP 153: 192.168.0.10.143 >
192.168.0.120.1045: P 1:113(112) ack 1 win 5440 (DF) (ttl 64, id 36901, len
152)} (DF) (ttl 64, id 0, len 189)
15:53:51.999217 0:2:2d:62:4b:75 0:0:cb:69:1c:43 0800 108: 217.186.85.9.1701
> 217.74.1.134.1701:  l2tp:[L](10732/39870) {IP 58: 192.168.0.120.1045 >
192.168.0.10.143: P 1:18(17) ack 113 win 17568 (DF) (ttl 64, id 2339, len
57)} (ttl 43, id 2340, len 94)
15:53:51.999620 0:0:cb:69:1c:43 0:0:cb:69:1c:43 0800 91: 217.74.1.134.1701 >
217.186.85.9.1701:  [udp sum ok] l2tp:[L](1/1) {IP 41: 192.168.0.10.143 >
192.168.0.120.1045: . [tcp sum ok] 113:113(0) ack 18 win 5440 (DF) (ttl 64,
id 36902, len 40)} (DF) (ttl 64, id 0, len 77)
15:53:52.000658 0:0:cb:69:1c:43 0:0:cb:69:1c:43 0800 218: 217.74.1.134.1701
> 217.186.85.9.1701:  l2tp:[L](1/1) {IP 168: 192.168.0.10.143 >
192.168.0.120.1045: P 113:240(127) ack 18 win 5440 (DF) (ttl 64, id 36903,
len 167)} (DF) (ttl 64, id 0, len 204)

all packets seem to have the DF-bit set... are there any packets to big?
i am unfortunately not so familiar with tcpdump-de-ciphering...

i would be grateful for ant tip / hint, as my possibilities and imaginations
are 
exhausted after 1 week of trouble-shooting ;-) , and maybe other people
are facing the same problems...

so, thanx a lot in advance,
greetz,
bernhard



        



[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic