Hello! Could someone please kindly help me with a Freeradius & VPN issue? Any help would be very appreciated! I'm a non native speaker, so please accept my apologies if I'm not totally clear with my language. It's an issue with a net equipment that implements VPN connections and an the authentication server (implemented with Freeradius). We work with several software providers who connect with our Intranet through the VPN, in order to make their web applications maintenance tasks. The clients are connected without problems for a long period of time during the night. But eventually the Freeradius (or vpn appliance, we don't know for certain) suddently disconnect the clients from the VPN during the next day in the morning (when our partners are working). Actually several times (maybe 6 times). They should login again (via automated pppd script and a watchdog). This watchdog also tries to keep open the VPN and if it's not open, it tries to reconnect the VPN again (like a heartbeat). The error we've seen in the log (we've used radmin and raddebug tools) is: "Acct-Terminate-Cause = 0" But in the Radius Accounting RFC (http://freeradius.org/rfc/rfc2866.html) this value is not permitted (possible values are 1-18). This is a piece of log, where you can see when a client disconnect from the vpn: Mon Jan 16 09:19:54 2012 Acct-Session-Id = "<sess_id_num>" Tunnel-Server-Endpoint:0 = "<IP_1>" Tunnel-Client-Endpoint:0 = "<IP_2>" Tunnel-Assignment-Id:0 = "PPTP" Framed-Protocol = PPP Framed-IP-Address = <IP_3> User-Name = "<usr_name>" Acct-Authentic = RADIUS Acct-Terminate-Cause = 0 Acct-Session-Time = 125159 Acct-Input-Octets = 1312452 Acct-Output-Octets = 2391455 Acct-Input-Packets = 19372 Acct-Output-Packets = 25170 Acct-Status-Type = Stop NAS-Port-Type = Virtual NAS-Port = 323 Service-Type = Framed-User NAS-IP-Address = <IP_4> Acct-Delay-Time = 0 Huntgroup-Name = "PPTP" Acct-Unique-Session-Id = "<acct_sess_id>" Stripped-User-Name = "<usr_name>" Realm = "NULL" Timestamp = 1326701994 Request-Authenticator = Verified <sess_id_num>, <acct_sess_id>, <IP_x> and <usr_name> aren't real values (they're masked for privacy) although I think the error isn't related to them. Thank you very much in advance!! Guillermo. --- Guillermo Bayon del Oso <guillermo_bayon@yahoo.com>
Guillermo Bayon del Oso wrote:
I'm a non native speaker, so please accept my apologies if I'm not totally clear with my language. It's an issue with a net equipment that implements VPN connections and an the authentication server (implemented with Freeradius).
Your language is fine.
We work with several software providers who connect with our Intranet through the VPN, in order to make their web applications maintenance tasks. The clients are connected without problems for a long period of time during the night. But eventually the Freeradius (or vpn appliance, we don't know for certain) suddently disconnect the clients from the VPN during the next day in the morning (when our partners are working). Actually several times (maybe 6 times).
If the user gets connected for a time, and THEN disconnected: blame the NAS (or VPN appliance). The explanation is simple: the user is allowed on the network after talking to FreeRADIUS. Then, without talking to FreeRADIUS, the user is disconnected. It can't be a FreeRADIUS issue.
The error we've seen in the log (we've used radmin and raddebug tools) is:
"Acct-Terminate-Cause = 0"
But in the Radius Accounting RFC (http://freeradius.org/rfc/rfc2866.html) this value is not permitted (possible values are 1-18).
Ah, yes. The VPN software is broken. This is fairly common. FreeRADIUS follows the RFCs. NAS / VPN software... not so much.
<sess_id_num>, <acct_sess_id>, <IP_x> and <usr_name> aren't real values (they're masked for privacy) although I think the error isn't related to them. Thank you very much in advance!!
Call up the vendor of the VPN appliance, and ask them why their product doesn't work. If they argue, point out that I'm the author / co-author of many RADIUS RFCs, include 5080, 6158, and others. They can believe their internal engineers who know nothing about RADIUS. Or, they can believe someone who wrote the specifications describing the protocol. Alan DeKok.
participants (2)
-
Alan DeKok -
Guillermo Bayon del Oso