Troubleshooting RUTXR1 L2TP over IPsec LAN Access Guide

After the forwarding path and return route are corrected, the Windows L2TP client at 192.168.250.20 can reach LAN devices through the RUTXR1, and LAN hosts can return traffic through 192.168.250.1. Follow the packet from the Windows client through IPsec, L2TP, routing, firewall forwarding, and the destination host.

Which network path must pass the packet?

The request starts on the Windows laptop, enters the L2TP session, crosses the IPsec-protected WAN path, terminates on the RUTXR1, and then leaves through the LAN interface. The reply must traverse the same functions in reverse. A successful ping to 192.168.250.1 proves that the laptop can reach the router through the VPN. It does not prove that the router permits forwarding from the L2TP client to the LAN.

Layer one first: from the RUTXR1 CLI, ping the intended LAN device. Check its link state, address, mask, and local firewall if that test fails. Continue only after the router can reach the LAN target directly.

Does the security association carry L2TP traffic?

On firmware RUTX_R_00.07.23.3, the attempted command ipsec status returns -ash: ipsec: not found. Use swanctl --list-sas for the active security associations.

The reported ipsec1 association is ESTABLISHED using IKEv1. Its child association, ipsec1_c_0, is INSTALLED as TRANSPORT-in-UDP. Both peers use UDP 4500, indicating IPsec NAT traversal. The child association also shows increasing inbound and outbound byte and packet counters. Those results prove that IKE negotiation, the IPsec child association, and protected traffic are active.

Reconnect the Windows VPN and run swanctl --list-sas twice while generating traffic. Verify that the association remains installed and that both packet counters increase before moving to routing checks.

Does each endpoint have the correct route?

Because the Windows client reaches 192.168.250.1, its L2TP address and route to the VPN endpoint are working. Inspect the Windows routing table while connected and confirm that the destination LAN subnet selects the L2TP interface. If Windows sends that subnet to its ordinary local gateway, add or correct the VPN route or change the client routing policy.

The return path is equally important. A LAN device replying to 192.168.250.20 must send the packet to a router with a route for the VPN client subnet. If the RUTXR1 is the LAN device's default gateway, it can normally route the reply locally. If another router is the gateway, add a route on that router for the VPN client subnet through the RUTXR1. Read the configured L2TP address pool and mask before creating the route; the two observed addresses alone do not define the complete subnet.

1. Connect the Windows VPN and confirm the assigned address is 192.168.250.20.
2. Inspect the Windows route selected for one specific LAN destination.
3. Inspect the LAN device's address, mask, and default gateway.
4. On the LAN gateway, confirm that the route for the configured VPN client pool points to the RUTXR1.

Prove the routing layer by tracing one destination in each direction and confirming that both endpoints select the RUTXR1 path.

Where does firewall forwarding stop?

Traffic addressed to 192.168.250.1 terminates on the router and passes through an input policy. Traffic addressed to another LAN device passes through a forwarding policy. The successful router ping and management-page access therefore do not validate VPN-to-LAN forwarding.

1. Open the RUTXR1 Traffic Rules configuration.
2. Create or correct a forwarding rule from the L2TP client network or VPN interface to the required LAN subnet and services.
3. If LAN devices must initiate sessions, add the reverse LAN-to-VPN forwarding permission.
4. Apply the rules and inspect their packet counters while repeating a ping.
5. Check the Windows firewall for inbound ICMP or application rules tied to the VPN network profile.

A counter that remains at zero means the packet did not match that rule; recheck its source interface, source subnet, destination subnet, protocol, and rule order. A rising allow-rule counter with no reply moves the fault to the LAN host, return route, reverse forwarding policy, or Windows host firewall.

Should NAT be used between the VPN and LAN?

Route the VPN client network whenever the LAN has a valid return route. Source NAT is not required merely because traffic crosses from L2TP to Ethernet. It can conceal a missing return route by translating 192.168.250.20 to a router address, but LAN devices then lose the original client address and cannot initiate a new connection back to that client through the same translation.

Temporarily disable an unneeded VPN-to-LAN NAT rule after the return route is installed. Verify that the destination device now records 192.168.250.20 as the source and still returns traffic.

How is the complete connection verified?

1. Disconnect and reconnect the Windows L2TP connection.
2. Confirm that Windows receives 192.168.250.20 and that 192.168.250.1 responds.
3. Run swanctl --list-sas and confirm ipsec1 is ESTABLISHED, ipsec1_c_0 is INSTALLED, and both packet counters advance.
4. Ping a LAN device from the RUTXR1 to prove the local LAN path.
5. Ping the same device from Windows and confirm that the VPN-to-LAN forwarding-rule counter advances.
6. From a LAN computer, test 192.168.250.20 or the required application service. Confirm the reverse forwarding counter advances and the Windows firewall permits the request.

The final pass condition is bidirectional application traffic between 192.168.250.20 and a LAN device, with active IPsec counters, matching firewall counters, and no unintended source translation.

FAQ