We are running into a very strange problem with our network. It has multiple L2TP/IP Sec links between our nodes and routing management is done via OSPF. We are still running 6.49.6 throughout our network. All good.
Last year, the L2TP links between AT&T fiber and our European nodes would not any longer connect. No change to configuration. We traced down the problem to an Internet exchange in New York. The problem seems to be that a server response is lost in the network. Please refer to the L2TP model as described in Wikipedia here https://en.wikipedia.org/wiki/Layer_2_T ... g_Protocol see section "L2TP packet exchange”.
When connection from <Client IP> to <Server IP>, the following interaction takes place (as observed in the packet sniffer on both sides):
- Client issue a SCCRQ call to <Server IP> (141 bytes)
- The server respons with a SCCRP response to <Client IP> (140 bytes)
- The client sends a SCCCN call (64 bytes)
- The server responds to the SCCCN call with a 54 byte reply, but that reply never reaches the client.
The net result of the missing packet is that the client does not go to the next step and request a session as it thinks that the server is “dead”. It therefore restart on 1) instead of issuing a ICRQ call.
The strange thing is that from Comcast, Optimum, etc (DOCSIS ISPs) we don't have this problem. When connection with an L2TP/IPSec client e.g. Mac it works, and AT&T therefore claim that the problem is with our Tiks.
The workaround has been to check the "Use IPsec" flag in the L2TP dial-out dialog. The encoding on the L2TP connection changes from "MPPE128 stateless" to "cbc(aes) + hmac(sha1)". It uses the default IPSec policy that prevents us from assigning static IP addresses to the tunnel and therefore making the OSPF management harder. We can also create a PPTP link, but this has obviously other security related problems.
Has anyone else experienced this problem? Is there another workaround possible so that we can statically assign IP addresses to the tunnel endpoints in the IPSec Policy and not rely upon the default policy?
Any help or insight into this challenge would be appreciated.