[Openswan Users]

Tomasz Grzelak tgrzelak at wktpolska.com.pl
Tue Aug 1 10:03:22 CEST 2006


Paul Wouters wrote:
> On Mon, 31 Jul 2006, Tomasz Grzelak wrote:
> 
>> Jul 31 13:52:58 localhost pluto[19518]: "roadwarrior"[2] W.X.Y.Z #2:
>> STATE_QUICK_R2: IPsec SA established {ESP=>0x92103582 <0xb8fbb2f0
>> xfrm=3DES_0-HMAC_MD5 NATD=W.X.Y.Z:13631 DPD=none}
> 
> Ok, so it is actually setting up NAT properpy.
> 
>> Jul 31 13:52:57 localhost pluto[19518]: | add inbound eroute W.X.Y.Z/32:1701
>> --17-> A.B.C.D/32:1701 => tun.10000 at A.B.C.D (raw_eroute)
> 
> Oh, this is for transport mode IPsec.... Duh. of course, you showed the l2tp bit.
> 
> Try setting the openswan external interface to an mtu of 1472 and see if that
> fixes things. Unfortunately, transport mode NAT'ed IPsec connections are very
> complex and sensitive to get working. :(

well, a long time ago I configured transport mode IPSec connection to 
Openswan 2.2.0 (Debian Woody, kernel 2.6.9), and it has been working 
'til the present day no matter the client is NATed or not; I had no 
problems such as now

any way, I made another test - I dialed up to my telco, got a public IP, 
and tried to connect to Openswan 2.4.5 and 2.4.6rc5. I had the errors on 
l2tpd:

l2tpd[3047]: control_finish: Peer requested tunnel 4 twice, ignoring 
second one.
l2tpd[3047]: control_finish: Peer requested tunnel 4 twice, ignoring 
second one.
l2tpd[3047]: control_finish: Peer requested tunnel 4 twice, ignoring 
second one.
l2tpd[3047]: Maximum retries exceeded for tunnel 42074.  Closing.
l2tpd[3047]: Connection 4 closed to 213.76.39.241, port 1701 (Timeout)

The IPSec SA was established successfully. So the problem is not related 
with NAT I think:

Aug  1 08:32:11 localhost pluto[2951]: | route_and_eroute: instance 
"roadwarrior"[4] 213.76.39.241, setting eroute_owner 
{spd=0x8109db4,sr=0x8109db4} to #5 (was #0) (newest_ipsec_sa=#0)
Aug  1 08:32:11 localhost pluto[2951]: | complete state transition with 
STF_OK
Aug  1 08:32:11 localhost pluto[2951]: "roadwarrior"[4] 213.76.39.241 
#5: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug  1 08:32:11 localhost pluto[2951]: | inserting event 
EVENT_SA_EXPIRE, timeout in 3600 seconds for #5
Aug  1 08:32:11 localhost pluto[2951]: "roadwarrior"[4] 213.76.39.241 
#5: STATE_QUICK_R2: IPsec SA established {ESP=>0x57fd5b67 <0x7c1d7d10 
xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}

The are no responses sent to the client.
Please, have a look at the routing table and the tcpdump log - there are 
some suspicious records.
The routing table:

----------------------------------------------------------------------------
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
213.76.39.241   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.20.20.0     0.0.0.0         255.255.255.240 U     0      0        0 eth1
A.B.C.128   0.0.0.0         255.255.255.240 U     0      0        0 eth0
0.0.0.0         A.B.C.129   0.0.0.0         UG    0      0        0 eth0
----------------------------------------------------------------------------

After the client had connected, the first route appeared in the routing 
table.
Look also at the tcpdump log:
(there are lots of 'arp who-has 213.76.39.241 tell A.B.C.D' - maybe the 
problem is with the routing?):

----------------------------------------------------------------------------
08:39:50.426782 IP 213.76.39.241.500 > A.B.C.D.500: isakmp: phase 1 I iden
t
08:39:50.722969 IP A.B.C.D.500 > 213.76.39.241.500: isakmp: phase 1 R iden
t
08:39:51.209564 IP 213.76.39.241.500 > A.B.C.D.500: isakmp: phase 1 I iden
t
08:39:51.369684 IP A.B.C.D.500 > 213.76.39.241.500: isakmp: phase 1 R iden
t
08:39:52.053946 IP 213.76.39.241.500 > A.B.C.D.500: isakmp: phase 1 I iden
t[E]
08:39:52.609778 IP A.B.C.D.500 > 213.76.39.241.500: isakmp: phase 1 R iden
t[E]
08:39:53.340915 IP 213.76.39.241.500 > A.B.C.D.500: isakmp: phase 2/others
  I oakley-quick[E]
08:39:53.989820 IP A.B.C.D.500 > 213.76.39.241.500: isakmp: phase 2/others
  R oakley-quick[E]
08:39:54.420433 IP 213.76.39.241.500 > A.B.C.D.500: isakmp: phase 2/others
  I oakley-quick[E]
08:39:54.460979 IP 213.76.39.241.500 > A.B.C.D.500: isakmp: phase 2/others
  I oakley-quick[E]
08:39:54.473938 IP A.B.C.D.500 > 213.76.39.241.500: isakmp: phase 
2/others 
              R inf
08:39:54.499749 IP 213.76.39.241 > A.B.C.D: ESP(spi=0xbee8a589,seq=0x1)
08:39:55.212227 IP 213.76.39.241 > A.B.C.D: ESP(spi=0xbee8a589,seq=0x2)
08:39:56.505225 arp who-has 213.76.39.241 tell A.B.C.D
08:39:57.251256 IP 213.76.39.241 > A.B.C.D: ESP(spi=0xbee8a589,seq=0x3)
08:39:57.505285 arp who-has 213.76.39.241 tell A.B.C.D
08:39:58.505349 arp who-has 213.76.39.241 tell A.B.C.D
08:40:00.505476 arp who-has 213.76.39.241 tell A.B.C.D
08:40:01.236251 IP 213.76.39.241 > A.B.C.D: ESP(spi=0xbee8a589,seq=0x4)
08:40:01.505541 arp who-has 213.76.39.241 tell A.B.C.D
08:40:02.505608 arp who-has 213.76.39.241 tell A.B.C.D
08:40:03.513661 arp who-has 213.76.39.241 tell A.B.C.D
08:40:04.513725 arp who-has 213.76.39.241 tell A.B.C.D
08:40:05.513786 arp who-has 213.76.39.241 tell A.B.C.D
----------------------------------------------------------------------------

It looks like the server does not know how to reach the client, so no 
responses are sent. Can you explain how to correct this? It looks like 
the reason of my problems.

Can you also look at my ipsec.conf file and tell me if it is correct to 
support roadwarriors? (I sent it in my first mail, but I can attach it 
again if you want).

Thank you,
Tomasz Grzelak


More information about the Users mailing list