FreeRADIUS: Firewall rules required for proxy?
-
Hi,
Does there need to be any firewall rules in place to allow the FreeRADIUS service to connect to a proxy RADIUS server?
I have a Kerberized RADIUS server on VLAN#2 that is tested and working. I have modified the proxy.conf file to point at this server, and the freeradius.inc file to enable the use of the proxy.conf.
In the system logs for pfSense, I can see this:
Mar 12 18:37:39 radiusd[69519]: Loaded virtual server <default>Mar 12 18:37:39 radiusd[69803]: Ready to process requests. Mar 12 18:38:18 radiusd[69803]: Marking home server 10.x.x.x port 1812 as zombie (it looks like it is dead). Mar 12 18:38:22 radiusd[69803]: No response to status check 1 for home server 10.x.x.x port 1812 Mar 12 18:38:31 radiusd[69803]: WARNING: Unresponsive thread 0 for request 0, in component <core>module Mar 12 18:38:32 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:38:33 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:38:35 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:38:39 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:38:44 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:38:51 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:38:59 radiusd[69803]: No response to status check 2 for home server 10.x.x.x port 1812 Mar 12 18:38:59 radiusd[69803]: Marking home server 10.x.x.x port 1812 as dead. Mar 12 18:39:03 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:39:20 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:39:29 radiusd[69803]: No response to status check 3 for home server 10.x.x.x port 1812 Mar 12 18:39:45 radiusd[69803]: WARNING: Child is hung for request 0 in component <core>module . Mar 12 18:39:58 radiusd[69803]: No response to status check 6 for home server 10.x.x.x port 1812</core></core></core></core></core></core></core></core></core></core></default>
This makes me think that the configuration is right, as it is trying to send my radtest calls made on VLAN#1 to the pfSense box to the right IP for the server on VLAN#2.
However, something seems to be blocking/dropping the traffic, and I can't tell what. I have done the same radtest directly against the VLAN#2 server from another client on the same network, so it is contactable.
Does the protocol require more than just UDP?
Regards,
Rob. -
An additional oddity, I just ran pfSense's packet capture tool, attaching it to the VLAN#2 interface, watching for UDP packets on port 1812.
If the pfSense address for VLAN#1 is on 10.1.1.1, the address for VLAN#2 is 10.1.2.1 and the RADIUS server is on 10.1.2.2, then this is what I saw:
20:45:27.007160 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:46:02.421450 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:46:35.310822 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:47:10.040224 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:47:43.781527 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:48:18.391873 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:48:49.878149 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68 20:49:23.281517 IP 10.1.1.1.1814 > 10.1.2.2.1812: UDP, length 68
Why does the RADIUS proxy on the pfSense box route packets straight from the listening address on VLAN#1 to the server on VLAN#2?
Does the client firewall on the RADIUS server need to accept packets from the 10.1.1.1 address? At the moment it only accepts them from 10.1.2.1 as that was where I was expecting them to come from.
Regards,
Rob. -
Solved.
In answer to the question, there are no special firewall rules required. RADIUS authenticates over port 1812 (accounting is 1813) and the proxy listener that proxy messages are sent from is listening on port 1814 (there is a port 1816 for service status requests, but it does not appear to be necessary). Since the proxy listener initiates the request from the pfSense installation, no outbound rule is required on the VLAN#2 interface, and no special inbound rules are required for the response.
As to what was wrong, if you are going to setup a proxy.conf file on your pfSense installation, make sure you add a proxy interface entry under interfaces.
It seems that by default the FreeRADIUS implementation puts the proxy listener on the first interface address that is not the localhost. In my case it placed it on the 10.1.1.1 address for VLAN#1 as that was the first entry under the interfaces list. Do not try to use src_ipaddr in proxy.conf, it won't stop the default listener setup, and will typically result in the listener from this setting being assigned to a random port each time the RADIUS service is started.
Without the proxy interface entry, although the kernel routes the requests to the correct interface, it doesn't do anything to check the validity of the source IP for the interface listening address (apparently a well known issue). As a result, it was sending the packets out on to VLAN#2 from 10.1.2.1, but since the listener was on 10.1.1.1, the packets went out with the wrong IP address.
I now have a working FreeRADIUS proxy on my pfSense interfaces, with the actual authentication handled by a Kerberized RADIUS installation within a DMZ VLAN.
Regards,
Rob.