<div>Hi all<br></div><div><br></div><div>I have an openswan-2.6.19 NETKEY debian server installed in a DMZ with a public facing internet IP.</div><div><br></div><div>I'm trying to connect an XP SP3 roadwarrior which is behind a NAT router in another location. It seems as though the ipsec connection gets established but the L2TP packets get sent back from the server to the client unencrypted.</div>
<div><br></div><div><br></div><div>My openswan config is:</div><div>=================</div><div>config setup</div><div> plutodebug="control parsing"</div><div> protostack=netkey</div><div> nat_traversal=yes</div>
<div> virtual_private=%v4:<a href="http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12">10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12</a></div><div> </div><div>conn l2tp-psk-orgWIN2KXP</div><div> authby=secret</div>
<div> pfs=no</div><div> auto=add</div><div> rekey=no</div><div> left=%defaultroute</div><div> leftprotoport=17/1701</div><div> right=%any</div><div> rightprotoport=17/1701</div>
<div> rightsubnet=vhost:%priv,%no</div><div> </div><div><br></div><div>End of the openswan log output after connection is established (can provide more if necessary):</div><div>======================================</div>
<div>pluto[31691]: "l2tp-psk-orgWIN2KXP"[3] 220.233.x.x #5: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2</div><div>pluto[31691]: | inserting event EVENT_SA_EXPIRE, timeout in 3600 seconds for #5</div>
<div>pluto[31691]: "l2tp-psk-orgWIN2KXP"[3] 220.233.77.199 #5: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x2e33037b <0x93b165d4 xfrm=3DES_0-HMAC_MD5 NATOA=192.168.0.10 NATD=220.233.x.x:4500 DPD=none}</div>
<div><br></div><div><br></div><div>Tcpdump on the server: (Client internal IP: 192.168.0.10, Client NATd IP: 220.233.x.x, Server IP: 203.1.y.y)</div><div>======================================================</div><div>IP 220.233.x.x.500 > 203.1.y.y.500: isakmp: phase 1 I ident</div>
<div>IP 203.1.y.y.500 > 220.233.x.x.500: isakmp: phase 1 R ident</div><div>IP 220.233.x.x.500 > 203.176.y.y.500: isakmp: phase 1 I ident</div><div>IP 203.1.y.y.500 > 220.233.x.x.500: isakmp: phase 1 R ident</div>
<div>IP 220.233.x.x.4500 > 203.176.y.y.4500: NONESP-encap: isakmp: phase 1 I ident[E]</div><div>IP 203.1.y.y.4500 > 220.233.x.x.4500: NONESP-encap: isakmp: phase 1 R ident[E]</div><div>IP 220.233.x.x.4500 > 203.176.y.y.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]</div>
<div>IP 203.1.y.y.4500 > 220.233.x.x.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]</div><div>IP 220.233.x.x.4500 > 203.176.y.y.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]</div><div>IP 220.233.x.x.4500 > 203.176.y.y.4500: UDP-encap: ESP(spi=0xd6c2d71a,seq=0x1), length 148</div>
<div>IP 220.233.x.x.4500 > 203.176.y.y.4500: UDP-encap: ESP(spi=0xd6c2d71a,seq=0x2), length 148</div><div>IP 203.1.y.y.1701 > 220.233.x.x.1701: l2tp:[TLS](16/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() </div>
<div>IP 203.1.y.y.1701 > 220.233.x.x.1701: l2tp:[TLS](16/0)Ns=0,Nr=1 ZLB</div><div>IP 220.233.x.x.4500 > 203.176.y.y.4500: UDP-encap: ESP(spi=0xd6c2d71a,seq=0x3), length 148</div><div>IP 203.1.y.y.1701 > 220.233.x.x.1701: l2tp:[TLS](16/0)Ns=0,Nr=1 ZLB</div>
<div>IP 203.1.y.y.1701 > 220.233.x.x.1701: l2tp:[TLS](16/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() |..</div><div>......</div><div>......</div><div>As I see it, the server is trying to establish an l2tp conncetion directly back to the client NAT address and not going through the ipsec tunnel?</div>
<div><br></div><div><br></div><div><br></div><div>Then I just get this in the xl2tpd logs:</div><div>=============================</div><div>xl2tpd[31794]: control_finish: Peer requested tunnel 17 twice, ignoring second one.</div>
<div>xl2tpd[31794]: control_finish: Peer requested tunnel 17 twice, ignoring second one.</div><div>xl2tpd[31794]: network_thread: select timeout</div><div>xl2tpd[31794]: network_thread: select timeout</div><div>xl2tpd[31794]: network_thread: select timeout</div>
<div><br></div><div><br></div><div>This all works succesfully from a client which is NOT NATd in anyway.</div><div><br></div><div><br></div><div>Any ideas? Help is appreciated.</div><div><br></div>