Good morning
I have a CHR v 6.49.2 router that works as LNS to give connectivity via pppoe to our customers. our partner has a CISCO LAC.

our LNS authenticates sessions via RADIUS. everything works correctly, the client receives the IP address and from the PPPOE server I can ping it and vice versa.

the problem is that I cannot reach the l2tp client from the routers external to the PPOe server, for example the router that acts as a gateway to the pppoe server does not ping the client attested to the pppoe lns.

the network is in OSPF and on the gateway I see the route on the routing table. if I do a traceroute the packets stop at the pppoe server

if i use the same configuration but instead of using l2tp i use pure pppoe server everything works fine

so the question is, how can i make the ospf routers correctly see the l2tp client attested to the pppoe server?

Anyone who has encountered this problem?

I'm encountering a similar issue. I have a core network with five routers (v7.x) connected to five remote sites via Wireguard and/or L2TPipsec. OSPF is functioning just fine for this part of the system. The problem occurs when we use a VPN client to connect to the network for management. The Core router acts as the VPN concentrator for the L2TP/ipsec vpn tunnels. IP addresses are assigned to clients via a pool (10.11.12.0/24). I simply cannot get the core router to advertise the route via ospf using interface templates. The L2TP address of the core (10.11.12.1)shows up in the routing tables as a /32 address. It is useless as a gateway leading to 10.11.12.0/24. If I configure the core router to distribute connected routes, it works. However, now all the routes connected to the Core are distributed as external routes. I might be able to live with that, but it causes OSPF flapping on least one of the remote routers. I don't understand why that's happening, but it's not a viable solution. The issue is clearly a routing problem as traceroutes from the remote routers to a client on the VPN pool attempt to use the default gateway at the remote site rather than the tunnel interface. I work around that issue by assigning the remote router's default gateway a higher administrative distance (eg:220) so the default route advertised via the Core takes precedence. However, that cuts off our ability to access the network via it's public IP address. As you can see, I've been going in a bit of a circle. Is there a correct way to advertise the network used for a VPN pool?

Here's my (current attempt) interface template and the interfaces that have come up based on those paremeters:

Users in a branch need to establish virtual private dial-up network (VPDN) connections with the headquarters. Layer 2 Tunneling Protocol (L2TP) is deployed between the branch and the headquarters. The branch has no dial-up network, and its gateway functions as a Point-to-Point Protocol over Ethernet (PPPoE) server to allow Point-to-Point Protocol (PPP) dial-up data to be transmitted over the Ethernet. The branch gateway also functions as an L2TP access concentrator (LAC) to establish L2TP tunnels with the headquarters.

The gateway at the enterprise headquarters is configured as the L2TP network server (LNS) to establish L2TP connections between the branch and headquarters. The RADIUS server in the headquarters authenticates users and allocates IP addresses to the users.