Hi,
I have a FortiGate # 80F which has a working VPN with my Windows NPS (which is on one Windows AD DC) on Azure
All the clients on the LAN where 80F's internal port is can reach the server and do their authentication tasks.
80F can't: I can't ping DC from CLI console, and Radius Server connection status says " Can't contact RADIUS server ".
Radius server should be ok, since in another site it works. Since I can't ping it from CLI console, I suspect there's something wrong.
Can you help me please?
Thanks
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hi JakeBlues,
So you're saying that the NPS is a server hosted in Azure, which you presumably reach through an IPsec tunnel?
If so, check if your IPsec tunnel interface has an IP configured:
show sys interface remote-win | grep "set ip"
If there's no IP, that's the usual reason why traffic like this doesn't work.
There are two solutions to this:
1, Specific to this RADIUS object: Set source-IP for it
config user radius
edit "<nps-object-name>"
set source-ip <some-ip>
end
The source-IP should be an IP owned by the FortiGate (usually a "LAN-side" interface's IP), and it should also be an IP that NPS expects to talk to it. (remembering that in NPS you have a list of permitted clients + potentially source-IP restrictions in Connection Request Policies)
2, General solution for all local-out traffic: Set an IP for the tunnel interface.
Simply edit the VPN interface and give it an IP. There are additional configuration steps you may have to consider:
- Routing: the Azure side of the tunnel should recognize the new IP and know that it is reachable through the tunnel.
- Firewall policies: The Azure side needs to know that this traffic is permitted to pass.
- IPsec traffic selectors: There must be an IPSEC ESP SA that allows packets coming to/from this IP. If your selectors are 0.0.0.0/0->0.0.0.0/0, or they already include the new IP, you're good to go. Otherwise you may need to add a new phase2 to ensure this is allowed to pass through.
I'm running 7.2.5 and I have the source-ip configured, but no tunnel interface IP. Still, the debug log says
__fnbamd_rad_send-Error sending radius request: fd=10, Network is unreachable
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
Hi Lucas,
These 2 commands, you should leave it as default.
set interface-select-method specify
set interface "internal1"
Or if you want to specify it manually then it should be the outgoing interface to the remote RADIUS server, not "internal1".
I believe it should be set to your tunnel interface.
Nice, that indeed worked. Thank you!
most welcome. glad it helps
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1665 | |
1077 | |
752 | |
446 | |
220 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.