ppp-project
Calling-Station-Id not send to radius
Hello, When user connect to the server with radius authentication (radcli 1.4.0) the "Calling-Station-Id" don't send to radius server
/var/run/radattr.ppp0
Reply-Message Authentication Successful.
MS-CHAP2-Success \XXXS=DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Idle-Timeout 1800
Acct-Interim-Interval 60
I use StrongSwan for XL2TP , IKEv2 and IPSec .
Hi,
Just took a peek at the code, Calling-Station-Id most certainly should be sent to the radius server if remote_number or ipparam is available (it'll default to the former, and incorrectly in my opinion fall back to ipparam).
I don't see that there is anything to add here.
If instead it's about it not being written to the attribute file, since the Calling-Station-Id isn't contained in the response (Acess-Accept) from the radius server, it will not be written to the attribute file.
Use the environment variables from PPPD to get it in the various scripts.
Don't think there is anything to do here ...
@enaess, @chipitsine, @sthibaul, @alarig, @EasyNetDev, @anphsw, @dfskoll, @XWwalker, @kurt-vd, @nkukard, @kad, @tisj: What do you think?
I don't think there is anything to be done here. Calling-Station-Id is SENT to Radius, not returned from, thus don't belong in the radattr file, any scripts run from the pppd process can use environment values (Specifically $REMOTENUMBER) to obtain this value.
In the absence of any response to the comments from @jkroonza, I think we should close this.
Hi, I’ve tested multiple scenarios, and when connecting an Ubuntu server to FreeRADIUS or Cloudius (which is also a RADIUS server), the user’s Public IP address is not sent to the RADIUS server. I have tested almost every possible configuration.
The interesting part is that when the connection goes through Cisco Ocserv (RadCli and PAM), OpenVPN or IKEv2 (strongSwan) on the same server, the user’s IP address is correctly sent to the RADIUS server. However, when connecting through XL2TP and strongSwan using ppp, the connection ( accounting , multi login , traffic usage (input/output octets) ) is established and works but the user’s IP is not sent.
I haven't reached a clear conclusion yet, but I’m fairly confident the configuration is correct as far as possible.
@jkroonza @Neustradamus @paulusmack
@farshidpg a few questions:
How does xl2tpd invoke the pppd instance? simplest is to get from ps axf.
Your original report provided the radattr file - which contains the contents from the radius Accept (response to Access-Request). Which will (unless the radius server sends back a Calling-Station-Id attribute in the access accept, which makes no sense) never contain the calling station id.
I would thus like to not see that file, but rather the output from tcpdump capturing that access-request, something like "tcpdump -vni any -s0 host ${radius_server} and port 1812" should output the full packet as sent.
More likely cause is that pppd doesn't have access to the remote ip because in xl2tpd.conf you've set "pass peer = no".
You may want to use this patch on xl2tpd as well, if you're using ipparam for other purposes (like we are) but still want the remote calling station id (typically the remote IP address for L2TP connections, but could also the calling station id AVP from the L2TP protocol itself).
https://github.com/xelerance/xl2tpd/pull/248
In short: This patch will pass the remote IP as remotenumber to pppd independently of the value of pass peer, which will still pass it using ipparam (if, and only if, pass peer = yes - the default). But since we're using ipparam for other purpose it's very, very annoying for xl2tpd to set ipparam to an ip address (Thus we set pass peer = no). Additionally we've got a few downstream BNGs that picks up PPPoE connections and bridges them to our LNS as a LAC, and sets the remote number AVP in the l2tp protocol, and thus why we introduced the "trust remotenumber" option to override the calling station with the AVP value rather than the IP address. Don't set trust remotenumber unless you trust the LAC. But the patch on xl2tpd may solve your problem.
You'll note I've got another PR open on xl2tpd side, so if you intend to deal with >~500 incoming clients to xl2tpd, you may want to look into https://github.com/xelerance/xl2tpd/pull/277 as well.
If you test one or both of these, please do give them a "I've tested this" on xl2tpd side indicating they work for you, and that you'd like to see them included into xl2tpd upstream.
@jkroonza ThankYou I've tested this [jkroonza/xl2tpd/tree/remotenumber](https://github.com/jkroonza/xl2tpd/tree/remotenumber) and its work perfect .
Pass remotenumber to pppd. #248
@jkroonza ThankYou I've tested this jkroonza/xl2tpd/tree/remotenumber and its work perfect .
Awesome. Please mention that on https://github.com/xelerance/xl2tpd/pull/248 as well - it might help to get it merged for the next xl2tpd release.
@paulusmack @Neustradamus based on the feedback I believe we can close this - I don't have permission to do that.
@farshidpg: Can you edit your latest message? The specified link is not good.