Proxies "status-server" pings are broken when virtual server "status" is enabled
Hello, I've enabled the default virtual-server "status" to get some stats out of FR3. Default configuration except for the password off course. Works very well... gives nice info... but later I noticed that the remote proxies received Access-Rejects to their status-server pings. Made some tests and that's what I found. Normal case without the "status" virtual server enabled, I get the following output : rad_recv: Status-Server packet from host 195.176.12.14 port 1814, id=226, length=70 Message-Authenticator = 0x04be96ea125b0c4b93f1c79e3e2bae64 NAS-Identifier = "Status Check 1. Are you alive?" (0) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam (0) group post-auth { (0) - entering group post-auth {...} [snip of reply_log junk] (0) [reply_log] = ok (0) ? if (User-Name && "%{realm}" != 'hes-so.ch') (0) ? Evaluating (User-Name ) -> FALSE (0) ? Skipping ("%{realm}" != 'hes-so.ch') (0) ? if (User-Name && "%{realm}" != 'hes-so.ch') -> FALSE Sending Access-Accept of id 226 from 160.98.240.20 port 1812 to 195.176.12.14 port 1814 (0) Finished request 0. Now when the virtual-server "status" is enabled rad_recv: Status-Server packet from host 195.176.12.14 port 1814, id=180, length=70 Message-Authenticator = 0xf2c18ba68bae0de068bf8d9ed96b4c96 NAS-Identifier = "Status Check 0. Are you alive?" (0) WARNING: Unknown value specified for Autz-Type. Cannot perform requested action. (0) # Executing group from file /etc/freeradius/sites-enabled/eduroam (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/freeradius/sites-enabled/eduroam (0) group REJECT { (0) - entering group REJECT {...} (0) sql : expand: '.query' -> '.query' [snip of sql junk] (0) [sql] = ok (0) Finished request 0. Waking up in 0.3 seconds. Waking up in 0.6 seconds. (0) Sending delayed reject Sending Access-Reject of id 180 from 160.98.240.20 port 1812 to 195.176.12.14 port 1814 This comes from the fact that in the status virtual-server, the "Autz-Type status-server" stanza is defined. But in the current virtual server receiving the "ping" (eduroam) it's not defined,so it triggers an reject message. Well in the end it doesn't change much as the remote server will still mark the server alive after receiving 3 access-reject in response to his status-server. But is this behaviour wanted ? Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org
Sorry, forgot to update the mail subject. It is not broken. It just receives access-rejects ;) Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org
Hi,
This comes from the fact that in the status virtual-server, the "Autz-Type status-server" stanza is defined. But in the current virtual server receiving the "ping" (eduroam) it's not defined,so it triggers an reject message.
well, enable it then.
Well in the end it doesn't change much as the remote server will still mark the server alive after receiving 3 access-reject in response to his status-server.
correct
But is this behaviour wanted ?
depends. on you. there is no point in having an access-accept (using username/password) as thats a credential that could be leaked or stolen etc.... its actually just as good (and standard) to have a reject response....the remote server/local server still know that each other are alive! ideally, both servers handle status-server packets and a basic 'status ping' will work just as well. alan
On 28.01.2013 10:07, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
This comes from the fact that in the status virtual-server, the "Autz-Type status-server" stanza is defined. But in the current virtual server receiving the "ping" (eduroam) it's not defined,so it triggers an reject message.
well, enable it then.
Well in the end it doesn't change much as the remote server will still mark the server alive after receiving 3 access-reject in response to his status-server.
correct
But is this behaviour wanted ?
depends. on you. there is no point in having an access-accept (using username/password) as thats a credential that could be leaked or stolen etc.... its actually just as good (and standard) to have a reject response....the remote server/local server still know that each other are alive!
ideally, both servers handle status-server packets and a basic 'status ping' will work just as well. Nice, thanks for those precisions AlanB :)
On a side note, I have something fun going on in post-auth here. I want to bypass the post-auth section for Packet-Type == Status-Server. So I wrote : post-auth { if(Packet-Type != Status-Server){ reply_log if("%{realm}" !~ /.*hes-so.ch/){ sql } } Post-Auth-Type REJECT { sql } } But the logic is inverted when you look at the logs. Now on the log ... rad_recv: Status-Server packet from host 127.0.0.1 port 60277, id=12, length=38 Message-Authenticator = 0xc09707a123242d5bee7be80eb07b3128 (81) # Executing group from file /etc/freeradius/sites-enabled/eduroam (81) group Status-Server { (81) - entering group Status-Server {...} (81) [ok] = ok (81) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam (81) group post-auth { (81) - entering group post-auth {...} (81) ? if (Packet-Type != Status-Server) (81) ? Evaluating (Packet-Type != Status-Server) -> TRUE (81) ? if (Packet-Type != Status-Server) -> TRUE (81) if (Packet-Type != Status-Server) { (81) - entering if (Packet-Type != Status-Server) {...} And what's even more funny .... On an Access-Accept packet it says that Packet-Type != Status-Server -> FALSE :D rad_recv: Access-Accept packet from host 130.59.138.29 port 1812, id=129, length=189 MS-MPPE-Recv-Key = 0x180d7429b72d1ef1757290ed8a0f47e8f22583e1bcb704c208c89a405779ba0d MS-MPPE-Send-Key = 0x0602884e6fba66616fc31d0047a1947bc996d10034886589d1a7b4a2ef37879e EAP-Message = 0x03080004 Message-Authenticator = 0xbb3d302a9d2b4a124f70e8f49e1588dd User-Name = "anonymous@test.hes-so.ch" Proxy-State = 0x38 (110) # Executing section post-proxy from file /etc/freeradius/sites-enabled/eduroam (110) group post-proxy { (110) - entering group post-proxy {...} [snip of post_proxy_log junk] (110) [post_proxy_log] = ok (110) attr_filter.post-proxy : expand: '%{Realm}' -> 'DEFAULT' (110) attr_filter.post-proxy : Matched entry DEFAULT at line 103 (110) [attr_filter.post-proxy] = updated (110) Found Auth-Type = Accept (110) Auth-Type = Accept, accepting the user (110) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam (110) group post-auth { (110) - entering group post-auth {...} (110) ? if (Packet-Type != Status-Server) (110) ? Evaluating (Packet-Type != Status-Server) -> FALSE (110) ? if (Packet-Type != Status-Server) -> FALSE Sending Access-Accept of id 8 from 127.0.0.1 port 1812 to 127.0.0.1 port 56702 MS-MPPE-Recv-Key = 0x180d7429b72d1ef1757290ed8a0f47e8f22583e1bcb704c208c89a405779ba0d EAP-Message = 0x03080004 Message-Authenticator = 0xbb3d302a9d2b4a124f70e8f49e1588dd -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org
Hello, Any idea on the point below? Olivier On 28 janv. 2013, at 10:07, Olivier Beytrison <olivier@heliosnet.org> wrote:
On a side note, I have something fun going on in post-auth here. I want to bypass the post-auth section for Packet-Type == Status-Server. So I wrote :
post-auth { if(Packet-Type != Status-Server){ reply_log if("%{realm}" !~ /.*hes-so.ch/){ sql } } Post-Auth-Type REJECT { sql } }
But the logic is inverted when you look at the logs.
Now on the log ...
rad_recv: Status-Server packet from host 127.0.0.1 port 60277, id=12, length=38 Message-Authenticator = 0xc09707a123242d5bee7be80eb07b3128 (81) # Executing group from file /etc/freeradius/sites-enabled/eduroam (81) group Status-Server { (81) - entering group Status-Server {...} (81) [ok] = ok (81) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam (81) group post-auth { (81) - entering group post-auth {...} (81) ? if (Packet-Type != Status-Server) (81) ? Evaluating (Packet-Type != Status-Server) -> TRUE (81) ? if (Packet-Type != Status-Server) -> TRUE (81) if (Packet-Type != Status-Server) { (81) - entering if (Packet-Type != Status-Server) {...}
And what's even more funny .... On an Access-Accept packet it says that Packet-Type != Status-Server -> FALSE :D
rad_recv: Access-Accept packet from host 130.59.138.29 port 1812, id=129, length=189 MS-MPPE-Recv-Key = 0x180d7429b72d1ef1757290ed8a0f47e8f22583e1bcb704c208c89a405779ba0d MS-MPPE-Send-Key = 0x0602884e6fba66616fc31d0047a1947bc996d10034886589d1a7b4a2ef37879e EAP-Message = 0x03080004 Message-Authenticator = 0xbb3d302a9d2b4a124f70e8f49e1588dd User-Name = "anonymous@test.hes-so.ch" Proxy-State = 0x38 (110) # Executing section post-proxy from file /etc/freeradius/sites-enabled/eduroam (110) group post-proxy { (110) - entering group post-proxy {...} [snip of post_proxy_log junk] (110) [post_proxy_log] = ok (110) attr_filter.post-proxy : expand: '%{Realm}' -> 'DEFAULT' (110) attr_filter.post-proxy : Matched entry DEFAULT at line 103 (110) [attr_filter.post-proxy] = updated (110) Found Auth-Type = Accept (110) Auth-Type = Accept, accepting the user (110) # Executing section post-auth from file /etc/freeradius/sites-enabled/eduroam (110) group post-auth { (110) - entering group post-auth {...} (110) ? if (Packet-Type != Status-Server) (110) ? Evaluating (Packet-Type != Status-Server) -> FALSE (110) ? if (Packet-Type != Status-Server) -> FALSE Sending Access-Accept of id 8 from 127.0.0.1 port 1812 to 127.0.0.1 port 56702 MS-MPPE-Recv-Key = 0x180d7429b72d1ef1757290ed8a0f47e8f22583e1bcb704c208c89a405779ba0d EAP-Message = 0x03080004 Message-Authenticator = 0xbb3d302a9d2b4a124f70e8f49e1588dd
--
Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mobile: +41 (0)78 619 73 53 Mail: olivier@heliosnet.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 29 Jan 2013, at 23:29, Olivier Beytrison <olivier@heliosnet.org> wrote:
Hello,
Any idea on the point below?
Is this with 3.0? Maybe it's looking at the packet code in the original request? I'll have a quick look now and see if there's anything obvious. -Arran
On 31 Jan 2013, at 10:14, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 29 Jan 2013, at 23:29, Olivier Beytrison <olivier@heliosnet.org> wrote:
Hello,
Any idea on the point below?
Is this with 3.0? Maybe it's looking at the packet code in the original request?
*not Though I don't know why status-server would be any different. IIRC Packet-Type was a hacked in attribute in xlat.c, have you tried the xlat version of the comparison? -Arran
Yeah it's 3.0. But it works for other values of packet-type (accounting for example) I'll come back from London tonight and will investigate this weekend. On 31 janv. 2013, at 18:22, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 31 Jan 2013, at 10:14, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 29 Jan 2013, at 23:29, Olivier Beytrison <olivier@heliosnet.org> wrote:
Hello,
Any idea on the point below?
Is this with 3.0? Maybe it's looking at the packet code in the original request?
*not
Though I don't know why status-server would be any different. IIRC Packet-Type was a hacked in attribute in xlat.c, have you tried the xlat version of the comparison?
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Olivier Beytrison wrote:
Well in the end it doesn't change much as the remote server will still mark the server alive after receiving 3 access-reject in response to his status-server.
But is this behaviour wanted ?
Yes. It's hard to change it. It's hard to know what *else* to do. The only other option is to *not reply* when the "status-server" section is missing from the virtual server. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Olivier Beytrison