L2TP dialup is successful but communication on the private network fails

25

The possible causes are as follows:
- The intranet host is enabled with the firewall.
- The local subnet and remote intranet are on the same network segment.
- The address for L2TP dialup access and addresses of LAN users are on the same network segment, but proxy ARP is disabled.
- The MTU on the virtual interface is set improperly. It is recommended that this MTU plus all the header lengths should not exceed the interface MTU. Otherwise, if a device does not support fragmentation, packets will be discarded.
- The TCP MSS on the virtual interface is set improperly. Ensure that the MSS plus all the header lengths should not exceed the interface MTU. Otherwise, packet transmission is affected.
- LCP renegotiation is not configured.
- Routes are unreachable.
- Tunnel authentication is not configured.
- Data protected by IPSec does not match an ACL.

Other related questions:
A user successfully initiates L2TP dialup, but cannot access the private network. Why?
A user successfully initiates L2TP dialup, but cannot access the private network. The possible causes are as follows: - The firewall is enabled on the intranet host. - The local and remote devices are on the same network segment. - The access address through L2TP dialup and LAN users are on the same network segment, and proxy ARP is not enabled. - The MTU on the virtual interface is incorrect. It is recommended that the MTU of the virtual interface plus all the header lengths should not exceed the MTU of the interface. Otherwise, packets will be discarded if some devices do not support fragmentation. - The MSS on the virtual interface is incorrect. Ensure that the MSS plus all the header lengths does not exceed the MTU. - LCP re-negotiation is not configured. - There are unreachable routes. - Tunnel authentication is not configured. - IPSec encryption is not configured and data flows do not match ACLs.

Why private network communication is delayed after the L2TP dialup is successful
L2TP encapsulation increases the length of IP packets. When the packet length exceeds the link MTU, the sender needs to fragment the packets, which are then reassembled by the receiver. Fragmentation and reassembly consume CPU resources. When many packets need to be fragmented, CPU resources will become insufficient, lowering the access speed and causing packet loss. Therefore, the MTU value on the VT interface must be less than or equal to the encapsulation header length of L2TP packets (42 bytes with a serial number, and 38 bytes otherwise) subtracted from the MTU value on the physical outbound interface (1500 bytes by default). For example, when the MTU value on the physical outbound interface is 1500 bytes by default, and the encapsulation header length of L2TP packets is 42 bytes, the value must be less than or equal to 1458 bytes. When the TCP packets encapsulated by L2TP exceed the link MTU, the ping operation to the private network will be delayed. In this case, web pages may not be displayed normally or remote logins may fail. You are advised to adjust the TCP MSS value on the VT interface to ensure that the length of TCP packets encapsulated by L2TP is less than or equal to the link MTU.

Why the private networks cannot communicate after the L2TP dialup is successful
When the L2TP dialup is successful, private networks may fail to communicate due to the following causes: -The firewall is enabled on the internal host. -The local subnet and the remote intranet are on the same network segment. -The L2TP dialup address is on the same network segment as the LAN user, but the proxy ARP function is disabled. -The MTU value on the virtual interface is improper. The MTU value plus all the header lengths cannot exceed interface MTU. Otherwise, the packets will be discarded if the device does not support packet fragmentation. -The TCP MSS value on the virtual interface is improper. Ensure that the MSS value plus all the header lengths cannot exceed the MTU. Otherwise the transmission of packets might be affected. -LCP renegotiation is not configured. -The LAC and LNS have no reachable routes to each other. -The tunnel authentication is not configured. -When IPSec encryption is used, the data flow does not match the ACL.

Why is there a delay in accessing the private network after successful L2TP dialup
The possible causes are as follows: -L2TP encapsulates IP packets. As a result, the IP packet length becomes longer. If the IP packet length exceeds the MTU during transmission, the IP packets are fragmented and sent. The receiver needs to reassemble and parse the fragments. Fragmentation and reassembly consume CPU resources. When there are many fragments, CPU resources may be insufficient. In this case, the access is slow and packets are discarded. The MTU of the virtual template interface must be smaller than or equal to the L2TP packet header length (42 bytes with the sequence number or 38 bytes without the sequence number) subtracted from the MTU value on the physical outbound interface (1500 bytes by default). For example, when the default MTU on the physical outbound interface is 1500 bytes and the L2TP packet header length is 42 bytes, the MSS must be smaller than or equal to 1458. -For TCP packets, when the length of TCP packets encapsulated with the L2TP header is larger than the MTU, there is a delay in performing the ping operation for the private network. As a result, an exception occurs in web page opening and remote login fails. You are advised to adjust the MSS of the virtual template interface so that the length of TCP packets encapsulated with the L2TP header is not larger than the MTU.

L2TP dialup is successful after several attempts, but the system displays error 691.
After the AR is configured with L2TP, users need to dial up multiple times. During dialup, the system displays error 691. This is because the AR supports challenge messages with only 16 bytes. When the length of challenge message is not 16, CHAP authentication fails. The system displays error 691 (incorrect user name or password). To solve the problem, configure L2TP re-negotiation so that the LNS and client negotiate 16-byte challenge messages.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top