Source interface for RADIUS auth traffic

[TO2020]

@viktor_g Thank you. Will the traffic always come from the same interface, or is it random?

[viktor_g]

@to2020 said in Source interface for RADIUS auth traffic:

@viktor_g Thank you. Will the traffic always come from the same interface, or is it random?

It comes from the "nearest" interface depending on the current routing table

[TO2020]

@viktor_g Thank you. So does this mean that if one of the LAN interfaces of the pfSense has IP address 10.1.2.1 and the internal RADIUS server is also in that same 10.1.2.0/24 subnet, it will always use that interface for all RADIUS communication?

And just to confirm, RADIUS traffic will originate from the interface IP address, not the CARP IP?

[stephenw10]

Yes and yes. An interface in the same subnet will always be logically closer than any other.

Steve

[TO2020]

@stephenw10 Thanks a lot for your reply, and for yours and @viktor_g assistance. Much appreciated.

[TO2020]

@viktor_g does this bug affect 2.6 as well? From the redmine link you had attached previously, it says it affects 2.5.2.
I am looking to migrate my RADIUS from my local network to a host in AWS and I connect to AWS with IPsec tunnels and FRR BGP where the VTI interfaces are using APIPA IP addresses.
When I do a packet capture, I see that the Diagnostic > Authentication traffic originates from the 169.254.x.x/30 IP of the active tunnel.
I am still running 2.5.2, but if this issue is resolved in 2.6, I will consider upgrading.

[stephenw10]

Yes, that is still present in 2.6. There have been no updates for it since 2.5.2 when it was first reported.

Steve

[TO2020]

@stephenw10 Thank you for the feedback. Does this issue also exist for LDAP authentication where the LDAP server specified is across that same IPsec VPN tunnel in AWS?

[stephenw10]

Yes, it also applies to LDAP. The source IP will be whatever is logically closest. Which in that case will be the unroutable APIPA address.

[TO2020]

@stephenw10 Thank you for the feedback. That is unfortunate.
Is there any workaround I can consider for this?

[stephenw10]

If you use policy based IPSec you can set a local route to force it to source from LAN:
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html#static-route-workaround

You could use some other VPN to the authentication server directly.

Steve

[TO2020]

@stephenw10
Hi Steve, thank you for the suggestions.
I do use VTI with FRR and BGP and have several connections to AWS for redundancy.

I think it could be challenging to create a separate VPN to AWS with static routes.
Since no work has been done on this issue, I am guessing it is hard to tell when a fix might be released?
I am just thinking of a workaround where I run this authentication service locally in my office for the time being.

/Thomas

[stephenw10]

Indeed there is no ETA on adding source IP as a feature.

You could maybe proxy the auth on the local server for pfSense.

A single IP VPN to something in AWS shouldn't be that difficult.

Steve

[TO2020]

@stephenw10 Thank you.

Wondering how others are managing this feature limitation with connectivity to AWS?
We have two internet lines on the corp side.
I have a pair of pfSense devices configured with CARP on all interfaces (WAN1, WAN2, LAN, etc).
I have two pairs of IPsec VPN tunnels to AWS (total 4 tunnels).
Right now I run FRR with BGP and tunnels in VTI mode. I guess I could configure these 4 tunnels in tunnel mode rather than VTI mode.
To achieve fully automated failover between either of these tunnels and corp side ISPs, could I use policy-based routing?

/Thomas

[stephenw10]

Policy based routing will only work using route based IPSec, it requires gateways to route via.

How is the Auth server hosted in AWS?

If you're able to setup any sort of tunnel to it directly from pfSense then it will use that tunnel IP instead which I would expect to work.

Steve

[TO2020]

@stephenw10
The auth servers are MS NPS role running on 2x EC2 workloads. I had hoped to be able to fully run this in AWS without deploying additional servers or services in my corp network.
The EC2 workloads are all located in my VPC. I have a virtual private gateway and I can configure either static routing (using Tunnel based VPN) or dynamic (using routed VTI based VPN), but with two internet lines on the corp side and a requirement for automatic failover and routing of traffic in the event that one of my corp-side ISPs is down, I assume I would need to use VTI-based VPN.
pfSense does not seem to support multiple static routes with different weight.
I did read about gateway groups and dynamic DNS, but failover could take minutes, which is unacceptable in a HA environment where all my production workloads are running in AWS.

My NPS servers are in their own subnets in my AWS VPC, e.g. my VPC is 10.100.0.0/16 where NPS servers are in 10.100.2.0/24 and 10.100.3.0/24 and all other workloads are in other /24 subnets.

I don't have any spare public IP addresses on my corp side. I am not sure if AWS will allow me to create multiple tunnels using the same customer gateway.

/Thomas

[stephenw10]

Hmm, well I'm not sure what the capabilities might be there but to make it work from pfSense you just need to create something with a more specific route. So that might be a GRE tunnel running over the IPSec that you route the two auth servers across.

[TO2020]

@stephenw10
I actually managed to make this work. I was speaking to AWS network engineers and we managed to route the APIPA traffic across the IPsec VPN tunnel to my EC2.
While everything you read about APIPA says that you cannot really use them for anything as they are not routable anywhere. I guess that is somewhat incorrect, as long as you manage the end to end connection.
This is what I did.
On pfSense side:
Added the local APIPA VTI interface IP address with /32 mask to "Networks to Distribute" list in FRR BGP.
When this is done, these routes should be propagated in your AWS VPC Private Routing Table.

On AWS side:
Make sure the same APIPA addresses/32 (from your pfSense) are added to the VPC Security Group you have applied to your EC2 instances where your RADIUS is running.

On your EC2 instances:
Allow access on UDP port 1812 (or whatever custom port you use) through Windows Firewall from any.
Add a static and persistent route to the pfSense APIPA address via the default gateway of that instance (route add -p 169.254.x.x mask 255.255.255.255 gateway metric 10)

With multiple tunnels, you will need to do this for all APIPA addresses used on your pfSense side.

In MS NPS, you will also need to add a Radius Client for each of the pfSense APIPA VTI address you have, as traffic will originate from any of them depending on which tunnel that is active.

Not sure if anyone can think of any security concerns around this?

/Thomas

[stephenw10]

Hmm, interesting. Yeah I really would not expect that to be routable anywhere. You should not be able to add that in AWS IMO.
The security implications are probably low given it's only a single IP.

Glad you found a solution. That sort of thing worries me though. AWS might decide to make that non-routable (correctly) in the future and that would then break it.

Steve

[TO2020]

@stephenw10
The AWS side will likely propagate whatever you advertise to it, because I manage both ends and that's just how the virtual private gateway works in AWS.
I guess there might be a slight risk here, but hopefully AWS won't make a change that reject these routes.

Of course, ideally I hope that pfSense will allow the source to be configured in a future release of the OS. As far as I know, other firewall vendors are able to do so.

/Thomas