Skip to main content
BWiebe
BWiebe
New Member
January 20, 2015
Solved

RADIUS Authentication Across VPN Tunnel

  • January 20, 2015
  • 4 replies
  • 34338 views

We recently moved a clients local server infrastructure to a collocate.  Currently they are connected to the infrastructure over a site-to-site VPN (soon to be a point-to-point connection).

 

As a result, their RADIUS server (NPS) is now across the VPN tunnel.  Their main site (outside the Collocate) has a number of FortiAPs that were configured to use WPA/Enterprise with the RADIUS server.  This stopped working after we converted them and I've been trying to fix this and we've temporarily implemented a different wireless network for them to work.  I can't seem to get the RADIUS working across the tunnel.

 

It seems to me - if I can control what IP the local Fortigate sends out to the Collocate, and the NPS servers, I should be able to resolve this by configuring the NPS server with a client corresponding to the IP.  I don't see anything in the NPS logs referencing this traffic, so it's like it's not even reaching the server.  The tunnel between sites allows any/all traffic across.

 

I found an old posting referencing a similar issue, but the directions seem to be only partially there.

 

Any thoughts on how to make this work?

 

Thanks!

Best answer by BWiebe

whofer wrote:

Hi there,

 

Were you able to solve it in the meantime? I'm fighting with exactly the same issue on a box with release 5.2.3 installed.

 

Thanks,

W.

Yes - I was able to solve this.  There was a bug in 5.2.2 - I haven't confirmed if it's there in 5.2.3.  Essentially, across the tunnel, the RADIUS test was pushing the IP across in reverse order (for example 10.50.0.1 was going to the RADIUS server as 1.0.50.10).  The solution was to not use the test in the GUI and test via CLI where there was no bug.

 

diag test authserver radius RADIUSSERVERNAME mschap2 username password

 

And I confirmed it was good.  So - I was fighting a GUI bug.

 

mschap2 can also be chap, pap or mschap, it is dependent on how your RADIUS is configured.

 

 

4 replies

Carl_Wallmark
Carl_Wallmark
New Member
January 21, 2015

Hi,

 

I think you need to set the "source-ip" on the radius server:

 

config user radius

edit <name of radius>

set source-ip x.x.x.x

end

 

the IP must be an IP address which can be routed accross the tunnel, for example the IP of the internal interface.

BWiebe
BWiebeAuthor
New Member
January 21, 2015

Selective wrote:

Hi,

 

I think you need to set the "source-ip" on the radius server:

 

config user radius

edit <name of radius>

set source-ip x.x.x.x

end

 

the IP must be an IP address which can be routed accross the tunnel, for example the IP of the internal interface.

Sorry - I should clarify - I actually did try this, but it doesn't seem to work for RADIUS.  It works fine for LDAP lookups, but not for RADIUS, for whatever reason.

 

 

whofer
whofer
New Member
April 27, 2015

Hi there,

 

Were you able to solve it in the meantime? I'm fighting with exactly the same issue on a box with release 5.2.3 installed.

 

Thanks,

W.

BWiebe
BWiebeAuthorAnswer
New Member
April 27, 2015

whofer wrote:

Hi there,

 

Were you able to solve it in the meantime? I'm fighting with exactly the same issue on a box with release 5.2.3 installed.

 

Thanks,

W.

Yes - I was able to solve this.  There was a bug in 5.2.2 - I haven't confirmed if it's there in 5.2.3.  Essentially, across the tunnel, the RADIUS test was pushing the IP across in reverse order (for example 10.50.0.1 was going to the RADIUS server as 1.0.50.10).  The solution was to not use the test in the GUI and test via CLI where there was no bug.

 

diag test authserver radius RADIUSSERVERNAME mschap2 username password

 

And I confirmed it was good.  So - I was fighting a GUI bug.

 

mschap2 can also be chap, pap or mschap, it is dependent on how your RADIUS is configured.

 

 

whofer
whofer
New Member
April 27, 2015

Hi,

 

Wow, thank you very much. But in this case it was simply my poor brain. I tried your hint on the CLI but still not working. After rechecking the whole configuration for the 10th time I found the cause: Simply one number in the IP address wrong :( :(. Sorry for bothering you with that.

 

But maybe one good thing I found out: The issue with the GUI error seems to be solved in 5.2.3.

 

Regards,

W.

lucasneumann
lucasneumann
Visitor III
November 14, 2023

This again seems to be an issue in 7.2.5.

Debug tells me:

__fnbamd_rad_send-Error sending radius request: fd=10, Network is unreachable

 

...when trying to contact the RADIUS server across the VPN tunnel.

My config looks like this, 10.200.25.1 is the LAN IP which is fully routed across all remote locations. 192.168.25.1 is a local RADIUS which works (next hop) and 192.168.69.3 is the RADIUS in the remote site, which does not work.

config user radius
edit "myRADIUS"
set server "192.168.25.1"
set secret ENC bla
set nas-ip 192.168.25.1
set source-ip "10.200.25.1"
set interface-select-method specify
set interface "internal1"
set secondary-server "192.168.69.3"
set secondary-secret ENC blabla
next
end

 

Terms & ConditionsAccessibility statement