Feature #9828
closedL2TP (long) username containing @ (realm separator)
100%
Description
Hi Team,
I’m trying to use pfSense as LNS via L2TP. However my LAC always includes a realm in the username.
For L2TP it’s not uncommon to use usernames containing a realm, in my case (the LAC is a mobile gateway) this results in a username like 31612345678@internet.mvno.mobi (this is a real world example that I currently use on Cisco, Juniper and FreeBSD/mpd5 with success.
This is currently not working with pfSende as special characters are not accepted as username.
Also (but I was unable to check) a realm often causes long usernames and not every l2tp implementation accept this.
My feature request is twofold:
1) please add support for special characters in usernames or at least allow “@“ as part of the username.
2) please make sure that long usernames (30+ characters) are possible
Let me know if you need more information, I can provide real world traces or additional information.
Updated by Manuel Piovan almost 5 years ago
/usr/local/www/vpn_l2tp_users_edit.php
change line 82
if (preg_match("/[^a-zA-Z0-9\.\-_]/", $_POST['usernamefld'])) {
to
if (preg_match("/[^a-zA-Z0-9\.\@\-_]/", $_POST['usernamefld'])) {
it save more than 30 char
-<l2tp>
-<user>
<name>admin.admin@123456789.123456789.123456789</name>
I can't test it though, if you want you can tell me if it work
Updated by Arjan van der Oest almost 5 years ago
I will try and report back ASAP, thanks for the ultrafast response, I truly appreciate it.
Updated by Arjan van der Oest almost 5 years ago
Well, changing the script allows to add the desired realms in the username, however the establishing of the l2tp tunnel fails before it comes to the authentication phase:
Oct 16 18:56:15 l2tps Incoming L2TP packet from x.x.52.55 13660
Oct 16 18:56:15 l2tps L2TP: Control connection 0x803252610 terminated: 0 ()
Oct 16 18:56:21 l2tps Incoming L2TP packet from x.x.52.54 13660
Oct 16 18:56:21 l2tps L2TP: Control connection 0x803252310 terminated: 0 ()
Oct 16 18:56:26 l2tps L2TP: Control connection 0x803252610 destroyed
Oct 16 18:56:32 l2tps L2TP: Control connection 0x803252310 destroyed
Oct 16 18:56:47 l2tps Incoming L2TP packet from x.x.52.55 13660
Oct 16 18:56:47 l2tps L2TP: Control connection 0x803252310 terminated: 0 ()
Oct 16 18:56:58 l2tps L2TP: Control connection 0x803252310 destroyed
When capturing the L2TP traffic on the LAC I can see it sends out the SccReq (Start Control Request) but is immediately turned down with a StopCCN (Stop Control Notification). The AVP Error-Result-Code is 0x4 : Requester is not authorized to establish a control connection. Normally this would mean I need to whitelist the LAC IP with a secret, but in pfSense I can't do this.
I checked and you actually use mpd so I checked /var/etc/l2tp-vpn/mpd.conf. What I'm missing here is a peer config, something like:
set l2tp peer x.x.52.55
set l2tp hostname $lns_hostname
set l2tp secret $lns_secret
After adding this, I killed mpd manually and restarted and then I'm able to connect:
Oct 16 19:34:24 l2tps [l2tp_b-1] IPCP: state change Req-Sent --> Ack-Sent
Oct 16 19:34:24 l2tps [l2tp_b-1] IPCP: rec'd Configure Ack #2 (Ack-Sent)
Oct 16 19:34:24 l2tps [l2tp_b-1] IPADDR 192.168.2.1
Oct 16 19:34:24 l2tps [l2tp_b-1] IPCP: state change Ack-Sent --> Opened
Oct 16 19:34:24 l2tps [l2tp_b-1] IPCP: LayerUp
Oct 16 19:34:24 l2tps [l2tp_b-1] 192.168.2.1 -> 192.168.2.16
Oct 16 20:18:24 pfSense l2tps: [l2tp_b-1] IFACE: No interface to proxy arp on for 192.168.2.16
Oct 16 20:18:24 pfSense l2tps: [l2tp_b-1] IFACE: Up event
Oct 16 20:18:24 pfSense l2tps: [l2tp_b-1] IFACE: Rename interface ng0 to l2tp1
Oct 16 20:18:24 pfSense l2tps: [l2tp_b-1] IFACE: Add group l2tp to ng0
This is odd, the manpage of mpd5.8 says:
Sets the peer IP address and port for the L2TP connection. This command applies to both incoming and outgoing connections. For outgoing connections, this command is required in order to specify where to connect to. For incoming connections, this command is optional; if not given, mpd accepts incoming connections from any host. Otherwise, only connections from the stated IP address (and, optionally, port) are allowed.
Ergo: the patch for the username (realm) works, can you commit this for future releases?
But it's not possible to implement a l2tp peer (plus secret, this actually doesn't seem to do anything). Should I raise a separate ticket for this config issues since this is an authentication ticket?
Updated by Manuel Piovan almost 5 years ago
sorry man didn't understand clearly what you where doing from the start..
revert back my mods, that page is for configuring the l2tp server
for configuring pfsense as client you must go to
Interface / assignements / ppps
press Add -> link type -> L2TP
Updated by Arjan van der Oest almost 5 years ago
I need a server, not a client :-)
The username/realm mod is exactly wat is needed and should me incorporated in the source, it’s very useful for others.
My remarks about what not working after the mod is odd, it should work with the current options in the GUI (no peer config) but it doesn’t. I can mod now, but clearly something is off and this needs further investigation. But technically that is outside the scope of this feature request :-)
How can I make sure this realm separator gets included in future releases?
Updated by Manuel Piovan almost 5 years ago
ok it's because it's late for me then ^^
don't worry, some dev will read and answer here asap, if they want a PR for only that line i can submit it if they want
Updated by Jim Pingle over 4 years ago
Any proposed changes should be submitted via pull request so they can be reviewed, discussed, and merged.
https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html
Updated by Viktor Gurov over 4 years ago
L2TP username containing @ (realm separator):
https://github.com/pfsense/pfsense/pull/4212
There is no issue with 30+ characters long usernames
Updated by Jim Pingle over 4 years ago
- Status changed from New to Pull Request Review
- Target version set to 2.5.0
Updated by Renato Botelho over 4 years ago
- Status changed from Pull Request Review to Feedback
- Assignee set to Renato Botelho
- % Done changed from 0 to 100
PR has been merged. Thanks!
Updated by Viktor Gurov over 4 years ago
- Status changed from Feedback to Resolved
works ok on 2.5.0.a.20200312.1334
Updated by Jim Pingle over 4 years ago
- Target version changed from 2.5.0 to 2.4.5-p1
Updated by Jim Pingle over 4 years ago
- Category changed from Authentication to L2TP