Hi Everyone,
For a lab test, I decided to use ACCEL-PPP with L2TP directly on a router running FRR (BGP)
I’m using Radius and Framed-IP-Address with FRR for L2TP and discovered I need to set the gw-ip-address interface address.
Which is fine, if you are using ACCEL-PPP downstream of your BGP router and have a defined gateway. If I don’t set a gateway address, I get the following errors:
warn: radius: gw-ip-address not specified, can't assign IP address...
warn: ppp0: ppp: no free IPv4 address
I’ve tried setting 127.0.0.1 as the gateway and a l2tp tunnel establishes but is not routable.
Any ideas please?
ACCEL-PPP with FRR router
Re: ACCEL-PPP with FRR router
Further to this, I've tried setting up a dummy interface.
ip link add name accel0 type dummy
ip addr add 10.0.0.1/24 dev accel0
ip link add name accel0 type dummy
ip addr add 10.0.0.1/24 dev accel0
Re: ACCEL-PPP with FRR router
Hello All,
I've been delving into configuring my setup and examining the radius.c file on GitHub for Accel-PPP. It appears that when using the Framed_IP_Address for each user, it verifies through conf_gw_ip_address to ensure a gateway is defined. I attempted to employ the Framed-Route attribute specified in Radius; however, it seems Accel-PPP does not support this, nor does it seem to handle CIDR notation.
From my understanding, implementing a route directive such as "0.0.0.0/0" to establish a default route is supposed to route all unspecified traffic based on the Network Access Server's (NAS) active routing table. Initially, I mentioned that using a dummy interface for the gw_ip_address led to the L2TP sessions being established with the IP address specified in Framed_IP_Address, rendering it unrouteable. However, upon further investigation, I discovered this issue was due to a configuration error on my part.
I noticed that conf_gw_ip_address relies on the inet_addr(opt) function, which, to my understanding, lacks CIDR support. I've successfully got ACCEL-PPP to work by setting 127.0.0.1 as the gateway, but considering it risky, I opted for creating a bridge with no interfaces, akin to a dummy interface, for use with Netplan. Utilising 172.10.10.1 has proven effective, albeit introducing an additional hop.
Comparing to l2tpns and examining the IP route, I see "xxxx.xxxx.xxxx.xxxx dev tun0 proto babel scope link", whereas with the bridge interface in Accel-PPP, it shows "XXXX.XXXX.XXXX.XXXX dev l2tp00 proto kernel scope link src 172.10.10.1". Is there a method to eliminate the dummy bridge interface, allowing the next hop to be the physical interface as per the NAS routing table? Currently, the dummy bridge interface is added to egress traffic.
I've been delving into configuring my setup and examining the radius.c file on GitHub for Accel-PPP. It appears that when using the Framed_IP_Address for each user, it verifies through conf_gw_ip_address to ensure a gateway is defined. I attempted to employ the Framed-Route attribute specified in Radius; however, it seems Accel-PPP does not support this, nor does it seem to handle CIDR notation.
From my understanding, implementing a route directive such as "0.0.0.0/0" to establish a default route is supposed to route all unspecified traffic based on the Network Access Server's (NAS) active routing table. Initially, I mentioned that using a dummy interface for the gw_ip_address led to the L2TP sessions being established with the IP address specified in Framed_IP_Address, rendering it unrouteable. However, upon further investigation, I discovered this issue was due to a configuration error on my part.
I noticed that conf_gw_ip_address relies on the inet_addr(opt) function, which, to my understanding, lacks CIDR support. I've successfully got ACCEL-PPP to work by setting 127.0.0.1 as the gateway, but considering it risky, I opted for creating a bridge with no interfaces, akin to a dummy interface, for use with Netplan. Utilising 172.10.10.1 has proven effective, albeit introducing an additional hop.
Comparing to l2tpns and examining the IP route, I see "xxxx.xxxx.xxxx.xxxx dev tun0 proto babel scope link", whereas with the bridge interface in Accel-PPP, it shows "XXXX.XXXX.XXXX.XXXX dev l2tp00 proto kernel scope link src 172.10.10.1". Is there a method to eliminate the dummy bridge interface, allowing the next hop to be the physical interface as per the NAS routing table? Currently, the dummy bridge interface is added to egress traffic.
Re: ACCEL-PPP with FRR router
Hi @tj-19, gw-ip-address in [radius] section required for p2p tunnels. You can use any not global routed IP for this like from 172.16.0.0/12, 10.0.0.0/8, 192.168.0.0/16...
Accel-ppp supports Framed-Route, and it works a bit different then you thought. It add route to BRAS likle <Framed-IP-Route> via <Client IP>
I rally dont get you problem, you can also use global routed IP address for p2p ([radius]gw-ip-address). As for FRR/BGP side you can adverdise connected. Chech ip route show in vtysh
Accel-ppp supports Framed-Route, and it works a bit different then you thought. It add route to BRAS likle <Framed-IP-Route> via <Client IP>
I rally dont get you problem, you can also use global routed IP address for p2p ([radius]gw-ip-address). As for FRR/BGP side you can adverdise connected. Chech ip route show in vtysh
Re: ACCEL-PPP with FRR router
Hi @dimka88, thank you for your valuable insights. I've successfully configured the gateway IP address to be 10.0.0.1. However, I'm still encountering an issue where the gateway IP address appears in the traceroutes for outbound traffic.
For incoming traffic, the routing table is respected, and the next hop immediately after the BGP router's external interface is the L2TP interface's framed IP address, which aligns with my expectations.
Here's an example of the outgoing traceroute, with specific IP addresses redacted for privacy:
Tracing the route to 8.8.8.8 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.5.1
2 1 ms 2 ms 1 ms 10.0.0.1
3 5 ms 6 ms 3 ms 84.xxx.xxx.xxx
4 3 ms 3 ms 3 ms 72.xxx.xxx.xxx
5 3 ms 4 ms 4 ms 192.xxx.xxx.xxx
6 4 ms 4 ms 4 ms 142.xxx.xxx.xxx
7 4 ms 4 ms 4 ms 8.8.8.8
Given that ACCEL-PPP and FRR are both operational on the same router, I find it unexpected and somewhat puzzling to see 10.0.0.1 appear in the traceroute for traffic exiting the network (outbound traffic). This inclusion raises questions, as it suggests the traffic may be redirected through this gateway, diverging from the next hop specified in the routing table. The reason behind its presence, or the necessity for it, might be related to the specific configuration of the L2TP tunnel or perhaps the default route setting that inadvertently directs traffic through this gateway. I'm curious about the underlying cause and wonder how it can be addressed.
Upon closer examination, the inet address assigned to each L2TP tunnel is 10.0.0.1, with the destination being the IP address provided in the framed IP address. This setup seems to influence the routing of outbound traffic, directing it through the 10.0.0.1 gateway in contradiction to the defined routes in the routing table.
How might I modify the configuration so that outbound traffic adheres more closely to the routing table, bypassing the 10.0.0.1 gateway? This would ensure that the route for traffic leaving the network accurately reflects the inbound traffic route and excludes the 10.0.0.1 gateway. Considering I'm assigning a /32 address to each L2TP tunnel, shouldn't this be sufficient for the router to manage the routing appropriately? I attempted to remove the 10.0.0.1 inet and set the framed IP address for the connection. Although I was able to receive ping responses, the L2TP tunnel failed to function correctly. The immediate ping response suggested that I was merely pinging the local L2TP interface directly on the router running ACCEL-PPP, indicating that traffic wasn't traversing the L2TP tunnel as expected.
In this use case, why do I need to define a gateway at all? Is there a way to disable or circumvent this requirement? My investigation into L2TPNS, in comparison, shows that only a /32 is used for the L2TP interface in each scenario. Could there be a similar approach I can adopt to eliminate the need for a gateway?
I would deeply appreciate any advice or suggestions on this matter.
For incoming traffic, the routing table is respected, and the next hop immediately after the BGP router's external interface is the L2TP interface's framed IP address, which aligns with my expectations.
Here's an example of the outgoing traceroute, with specific IP addresses redacted for privacy:
Tracing the route to 8.8.8.8 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.5.1
2 1 ms 2 ms 1 ms 10.0.0.1
3 5 ms 6 ms 3 ms 84.xxx.xxx.xxx
4 3 ms 3 ms 3 ms 72.xxx.xxx.xxx
5 3 ms 4 ms 4 ms 192.xxx.xxx.xxx
6 4 ms 4 ms 4 ms 142.xxx.xxx.xxx
7 4 ms 4 ms 4 ms 8.8.8.8
Given that ACCEL-PPP and FRR are both operational on the same router, I find it unexpected and somewhat puzzling to see 10.0.0.1 appear in the traceroute for traffic exiting the network (outbound traffic). This inclusion raises questions, as it suggests the traffic may be redirected through this gateway, diverging from the next hop specified in the routing table. The reason behind its presence, or the necessity for it, might be related to the specific configuration of the L2TP tunnel or perhaps the default route setting that inadvertently directs traffic through this gateway. I'm curious about the underlying cause and wonder how it can be addressed.
Upon closer examination, the inet address assigned to each L2TP tunnel is 10.0.0.1, with the destination being the IP address provided in the framed IP address. This setup seems to influence the routing of outbound traffic, directing it through the 10.0.0.1 gateway in contradiction to the defined routes in the routing table.
How might I modify the configuration so that outbound traffic adheres more closely to the routing table, bypassing the 10.0.0.1 gateway? This would ensure that the route for traffic leaving the network accurately reflects the inbound traffic route and excludes the 10.0.0.1 gateway. Considering I'm assigning a /32 address to each L2TP tunnel, shouldn't this be sufficient for the router to manage the routing appropriately? I attempted to remove the 10.0.0.1 inet and set the framed IP address for the connection. Although I was able to receive ping responses, the L2TP tunnel failed to function correctly. The immediate ping response suggested that I was merely pinging the local L2TP interface directly on the router running ACCEL-PPP, indicating that traffic wasn't traversing the L2TP tunnel as expected.
In this use case, why do I need to define a gateway at all? Is there a way to disable or circumvent this requirement? My investigation into L2TPNS, in comparison, shows that only a /32 is used for the L2TP interface in each scenario. Could there be a similar approach I can adopt to eliminate the need for a gateway?
I would deeply appreciate any advice or suggestions on this matter.
Re: ACCEL-PPP with FRR router
Hi @tj-19, I think does not possible to use ppp without GW in accel-ppp, this requir p2p route. Try to change GW to router IP address which you was in route path to client.
Re: ACCEL-PPP with FRR router
Hi @dimka88,
Thank you once again for your guidance on configuring the gateway IP with ACCEL-PPP. Following your suggestion, I've set the gateway to one of the router's interfaces.
However, this has made no difference. I am still observing a discrepancy in routing that I hope you can help me understand better.
Specifically, it concerns how the PPP interface manages the route paths differently for incoming (ingress) and outgoing (egress) traffic. After setting the gateway using gw_ip_address , all outgoing traffic routes through this specified interface as expected. This is clearly shown in traceroute tests, where the specified gateway appears as a hop for all egress traffic.
Conversely, the ingress traffic behaves differently. It doesn't seem to route through the specified gateway defined in gw_ip_address, and this hop doesn't appear in traceroute tests for ingress traffic. It's as if Linux routes the inbound traffic more directly, bypassing the hop defined by gw_ip_address and is not what I would expect to see, especially when comparing it to the egress traceroute.
This observation has led me to wonder if there's something inherent to the PPP configuration or Linux's handling of PPP connections that dictates this distinct routing behaviour for egress traffic. Given that the ingress route doesn't include this hop, could there be a mechanism within the PPP coding or Linux routing optimisations that enforces this behaviour?
Any insights or explanations you could provide would be greatly appreciated.
Thank you so much for your help.
Best wishes,
@tj-19
Thank you once again for your guidance on configuring the gateway IP with ACCEL-PPP. Following your suggestion, I've set the gateway to one of the router's interfaces.
However, this has made no difference. I am still observing a discrepancy in routing that I hope you can help me understand better.
Specifically, it concerns how the PPP interface manages the route paths differently for incoming (ingress) and outgoing (egress) traffic. After setting the gateway using gw_ip_address , all outgoing traffic routes through this specified interface as expected. This is clearly shown in traceroute tests, where the specified gateway appears as a hop for all egress traffic.
Conversely, the ingress traffic behaves differently. It doesn't seem to route through the specified gateway defined in gw_ip_address, and this hop doesn't appear in traceroute tests for ingress traffic. It's as if Linux routes the inbound traffic more directly, bypassing the hop defined by gw_ip_address and is not what I would expect to see, especially when comparing it to the egress traceroute.
This observation has led me to wonder if there's something inherent to the PPP configuration or Linux's handling of PPP connections that dictates this distinct routing behaviour for egress traffic. Given that the ingress route doesn't include this hop, could there be a mechanism within the PPP coding or Linux routing optimisations that enforces this behaviour?
Any insights or explanations you could provide would be greatly appreciated.
Thank you so much for your help.
Best wishes,
@tj-19
Re: ACCEL-PPP with FRR router
Imagine the foloowing topology
Trace from PPPoE Clinet
Trace from Some-Host
So, if accel-ppp configured with gw-ip-address which defined on R1 eth1 it works and show properly trace.
Trace from PPPoE Clinet
Code: Select all
traceroute 203.0.113.2
traceroute to 203.0.113.2 (203.0.113.2), 30 hops max, 60 byte packets
1 192.0.2.1 (192.0.2.1) 2.782 ms 1.527 ms 2.137 ms
2 192.0.2.2 (192.0.2.2) 4.410 ms 4.171 ms 3.981 ms
3 203.0.113.2 (203.0.113.2) 9.265 ms 14.511 ms 13.536 ms
Code: Select all
traceroute 192.0.2.100
traceroute to 192.0.2.100 (192.0.2.100), 30 hops max, 60 byte packets
1 203.0.113.1 (203.0.113.1) 1.442 ms 1.472 ms 1.432 ms
2 192.0.2.1 (192.0.2.1) 4.959 ms 15.949 ms 15.218 ms
3 192.0.2.100 (192.0.2.100) 30.638 ms 30.508 ms 30.385 ms