Description of problem: Basically the problem is that "ipparam" pppd variable is modifed by xl2tpd daemon during establishing of L2TP VPN (using pppd) once the xl2tpd is calling pppd. And this modification cannot be overridden by "ipparam" parameter within ppp option file - it will remains ignored. What this bahavior cause? - xl2tpd modifies "ipparam" variable to remote IP of connecting client (in general it is public source IPv4 address of incomming VPN connection requests from client) - this is done instead of fact, that remote IP of client is accessible via global REMOTEIP pppd variable. - and thus /etc/ppp/ipv6-up script (officially shipped with distribution) will always fail (returns 1) as it looks for configuration file of PPPDEVICE in form "ifcfg-X.X.X.X" where "X.X.X.X" is part given from "ipparam" provided within calling the ipv6-up script. This request is similar of following requests: - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635472 - https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/947404 Version-Release number of selected component (if applicable): xl2tpd-1.3.1-5.el6.x86_64 How reproducible: always Workaround: - yes I can use unsupported openl2tpd - or modify ipv6-{up|down} scripts, but those scripts will be always overwritten with every new release of initscripts package Main reasons for this report: - ipv6-up ppp script always fails - there is no official l2tp alternative for RHEL Additional info: - on mentioned web pages there is also patch provided for removing this unexpected modification of ipparam from xl2tpd.
Created attachment 718377 [details] ipparam-to-remotenumber patch This patch replaces "ipparam" with supported "remotenumber" variable. - this parameter "remotenumber" can be used analogously like "ipparam" for logging IP's of connecting VPN clients via RADIUS plugin (without any additional code modification), AND - this does not break ipv6-up script because ipparam can be defined to some meaningful value which allows matching specifed "ifcfg-$ipparam" config file and ipv6 configuration can seamlessly continues.
xl2tpd-1.3.1-13.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xl2tpd-1.3.1-13.fc18
xl2tpd-1.3.1-6.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/xl2tpd-1.3.1-6.el6
Package xl2tpd-1.3.1-6.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing xl2tpd-1.3.1-6.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0874/xl2tpd-1.3.1-6.el6 then log in and leave karma (feedback).
xl2tpd-1.3.1-13.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Sorry, but this patch actually does more evil than good. Since migration to F19 I've found that I couldn't see anywhere the LAC address (which was provided with ipparam) - and now, after checking changelogs, I know why. REMOTEIP is actual IP assigned to remote client, while ipparam is merely additional parameter which pppd adds as 6th parameter when calling up/down scripts (man pppd: it is not used anywhere for anything in pppd itself). Worse, "remotenumber" is not accessible in up/down scripts, thus making impossible to take any action in script based on LAC IP. Sure, you can still see it in radius logs - but only if you use or rely on radius, and don't need it in scripts (which is not always the case). Surely it may break ipv6-up/down scripts, but more correctly would be to fix ipv6-ip/down scripts instead of breaking long established (and expected) behavior. Therefore I kindly request to remove this patch, or at least, do it in the right way - add an option to xl2tpd which will control its behavior. Thank you!
re-opened to investigate
xl2tpd-1.3.6-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xl2tpd-1.3.6-1.fc20
xl2tpd-1.3.6-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xl2tpd-1.3.6-1.fc19
xl2tpd-1.3.6-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/xl2tpd-1.3.6-1.el6
Package xl2tpd-1.3.6-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xl2tpd-1.3.6-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6347/xl2tpd-1.3.6-1.fc19 then log in and leave karma (feedback).
xl2tpd-1.3.6-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
xl2tpd-1.3.6-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
xl2tpd-1.3.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
Hello, I can verify that the problem still persists on "xl2tpd-1.3.6-1.el6.x86_64". The variable "ipparam" isn't sent to radiusclient and therefore we receive empty "Calling-Station-Id" in our backend. If we manually set the ipparam variable in our /etc/ppp/options.xl2tpd we receive the seted value in our backend, which indicates that the bug is still here.