0

Our partner provides a service that is available only through the L2TP/IPSec tunnel. We successfully connect to it from Windows, but the connection hangs dead a couple of times a week. Therefore, I decided to set up L2TP/IPSec connection from Linux. But after weeks of trying, I never managed to do it. The connection establishes, but once it breaks: on the side of Cisco there appears an error "IKE lost contact with remote peer, deleting connection", and on the side of the client "received DELETE for ESP CHILD_SA with SPI".

I tried CentOS and FreeBSD, StrongSwan, LibreSwan and Racoon, XL2TPD and MPD5 - the same result! I tried to set up a connection on a machine with a public IP-address without firewalls and NATs - the same result! I asked in different forums, even in Cisco community, but they could not help.

Interestingly, the rupture of an IPsec connection occurs only after the establishment of an L2TP connection. If L2TP is not launched, then the IPSec connection remains valid (this can be seen from the "setkey -D" command).

The Windows machine with which we successfully connect is on the same network, which means our Internet provider is not to blame. Please help! The service provider has Cisco ASA 5550.

Client side logs

Cisco log

ipsec.conf

mpd.conf

yurybx
  • 11
  • 3

2 Answers2

0

According to your Strongswan/mpd5 logs, if they are from one instance - you have successfully established client l2tp/ipsec connection:

[B_uz] IPCP: LayerUp
[B_uz]   10.10.181.222 -> 195.149.70.70
[B_uz] IFACE: Add address 10.10.181.222/32->195.149.70.70 to ng2
[B_uz] IFACE: Up event
[B_uz] IFACE: Change interface ng2 flags: -0 +1

But then bad things started to happen:

EVENT: Processing event EVENT_READ LinkNgDataEvent() done
L2TP: RECV [MESSAGE_TYPE HELLO]
L2TP: rec'd HELLO in state established
EVENT: Processing event EVENT_TIMEOUT TimerExpires()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout()
[L_uz] LCP: no reply to 1 echo request(s)
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires() done
L2TP: XMIT [MESSAGE_TYPE HELLO]
EVENT: Processing event EVENT_TIMEOUT TimerExpires()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout()
[L_uz] LCP: no reply to 2 echo request(s)
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires() done
EVENT: Processing event EVENT_TIMEOUT TimerExpires()
EVENT: Processing timer "FsmKeepAlive" FsmEchoTimeout()
[L_uz] LCP: no reply to 3 echo request(s)

LCP (Line Control Protocol) echoes are not answered, thus connection is terminated. This is either a misconfigured [stateful] packet filter issue or, probably, a misconfigured DPD (Dead Peer Detection) issue. You need toi investigate further.

Also notice:

  • IPCP (IP Control Protocol) is sometimes failing to negotiate the IPs, you probably need to enhance your mpd5.conf in this part.
  • your mpd5 logs are eikther badly obfuscated or corrupted, this is a disturbing sign in the latter case.
drookie
  • 8,625
  • 1
  • 19
  • 29
  • You're right! The PPP-interface receives an IP-address that matches the address of the L2TP server, and all packets for this IP-address are trying to go through PPP-interface. Because of this, IPSec-packages cannot reach the supplier's L2TP server! Here is how the interface configuration in FreeBSD looks like (195.149.70.70 is L2TP-server's IP-address): `ng0: flags=88d1 metric 0 mtu 1410 inet 10.10.181.222 --> 195.149.70.70 netmask 0xffffffff nd6 options=29` – yurybx Mar 09 '19 at 20:05
  • And in the CentOS: `ppp0: mtu 1400 qdisc pfifo_fast state UNKNOWN group default qlen 3 link/ppp inet 10.10.181.222 peer 195.149.70.70/32 scope global ppp0 valid_lft forever preferred_lft forever` – yurybx Mar 09 '19 at 20:08
  • Why it happens? How to make MPD or L2TPD assign some private ip-ddress? By the way, if I add a line "set ipcp ranges 0.0.0.0/0 10.10.0.0/16" to mpd.conf, the PPP-interface cannot even get an IP address, and errors appear in the log: `IPADDR 195.149.70.70 NAKing with 10.10.0.0 IPCP: not converging IPCP: parameter negotiation failed IPCP: state change Ack-Rcvd --> Stopped` As for XL2TPD, I don’t even know how to manage the assignment of an address to an interface in it. Please, help! – yurybx Mar 09 '19 at 20:08
  • Try 0.0.0.0/0 for ipcp on the client side and let the server sude assign you IP. As about recursive routing - thats another story, and there’s no short answer here. – drookie Mar 09 '19 at 23:14
0

Using Drookie's hint, I began to dig further, and I managed to solve the problem! I did not manage to get the MPD5 to work, but XL2TPd+LibreSwan (in CentOS) works fine. I just added the line 

:10.0.0.1

to the "/etc/ppp/options.vpn-uz", and it all worked!

yurybx
  • 11
  • 3