How would I have RADIUS/NPS authenticate through another interface?
Our current RADIUS infrastructure is set up like so:
One Firebox M470 is setup with 2 ISPs setup as external interfaces. This is connected via a BOVPN to an Azure VM that acts as our RADIUS/NPS server. The RADIUS client is setup pointing to the local address setup in the BOVPN. The BOVPN has both external interfaces listed as local gateways with the remove gateway being Azure virtual network gateway.
We have 2 A records on our DNS, each pointing to a public IP associated with our ISPs. These are the external interfaces associated with our IKEv2 VPN.
The issue is, during testing when we pull the primary ISP, RADIUS is failing to authenticate through the secondary ISP. There's no issue authenticating through the primary ISP.
What we want to be able to do is ensure that if ISP 1/external interface 1 goes down, users are still able to authenticate and connect to the VPN using ISP 2/external interface 2.
We were thinking it could be a routing issue and are reading up on dynamic routing to see if we can apply BGP or OSPF. Would this be putting us on the right track?
Apologies if this comes off as convoluted. Any help in figuring this out would be much appreciated.
Answers
Hi @oluong
The firebox should be able to do this via multi-wan -- is the firebox detecting the primary interface as failed? If not, it will usually send traffic via the lowest numbered external interface unless there's a SD-WAN or Policy Based Routing rule telling it to send elsewhere.
-James Carson
WatchGuard Customer Support
@james.carson
We have multi-wan enabled. It is setup on the routing table setting. We set it that way to make use of both ISPs at the same time instead of failover.
When we were testing we would pull the primary ISPs interface, so I'm pretty sure it is showing failed. I'll have to visually confirm that tonight.
As for policies or SD-WAN, we do not have anything telling it to go to a specific interface. On that note, my experience with SD-WAN is limited, but from what I've been reading so far, I could set up a SD-WAN policy/action to route traffic if the primary ISP fails. Would this be viable? Or would that be going in the wrong direction?
Just some additional information after looking into the event viewer of the NPS server:
When I pull the primary ISP and try to authenticate through the IKEv2 VPN using the secondary ISP, nothing pops up in the event viewer of NPS server.
When it succeeds, it would show the NAS IP as the local IP that was setup on the BOVPN virtual interface.
There was one time it would pop up this:
A RADIUS message was received from the invalid RADIUS client IP address 162.xxx.xxx.xxx. But after that, no messages or errors when trying to connect.
It seems like the primary ISP will go through the BOVPN without issue, but the secondary either doesn't register, or it isn't going through the tunnel when the primary is down.
Hi @oluong
Is this going through NPS or something similar?
Make sure that the RADIUS server is set up to expect access from either IP, or it'll reject with a message like that. If you're using AuthPoint, a RADIUS resource should be set up for both IPs (if you're coming across it from the internet.)
-James Carson
WatchGuard Customer Support
@james.carson
The NPS is set up to expect traffic from the local IP set up on the BOVPN virtual interface. The BOVPN has both external interfaces set up as local gateways routing to the same remote gateway in Azure.
My understanding is that if the #1 gateway endpoint is down, wouldn't all traffic run through the #2 gateway endpoint to the remote gateway?
Is it not possible for 2 external interfaces to route through the BOVPN?
I'd suggest opening a support case so that one of our techs can dig in a bit further -- it sounds like we're getting a reject from somewhere upstream -- and if that's the case we'll need to figure out where it's coming from.
-James Carson
WatchGuard Customer Support