nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

External radius server

unknown

I have a bunch of ZD1200 and ZD3000 units at multiple sites. I am wanting to setup a Windows Server 2016 box to use NPS for radius. I am having a difficult time getting this to work. My best guess is an issue with routing/nat.

In my test lab I have a ZD behind a Cisco ASA. The ZD has a private IP but has internet access. The Radius server is behind another ASA with a private IP and has internet access. I can never get traffic all the way to the radius server from the ZD.

Can someone share some insight?

Thank you

Find more posts tagged with

Accepted answers

All comments

michael_brado

Hm, double NAT... what IP do you tell the ZD to use for your RADIUS server, and vice versa?
You probably need routes to those IPs on the inside of both sides, and port-forward of the IP to their NAT-translated inside IPs (on both sides).
Have you sniffed your wire to see if packets go out and/or ever come back (on either side)?

unknown

On the ZD i told it the radius server was the public IP that the radius server was on. then on the windows NPS i gave the public IP that the AP i was connecting to was on.

I did port forwarding on the ASA that the Windows NPS server is on to forward port 1814 to the private IP of the radius server.

I could give the radius server it's own public IP and not have to use NAT on it. On the ZD side how did you configure the nat to work?

Thank you for your response.

tony_heung

It is worth running packer-tracer on the ASA inside interface (on the ZD side) to the NPS ip. You can verify if all the phases are permitted (eg: UN-NAT, ACLs, NAT, IP-OPTIONS, and FLOW-CREATION), and the final message should be "ALLOW". I had seen issue without inspection map configured so running the packet-tracer can isolate the issue not on the ASA config, then you can focus on the endpoints (ie: ZD and NPS).

--tony

unknown

tony,

According to packet trace I am able to choose the outside interface. The source IP of the public IP of the ZD to the private IP of the NPS server on port 1814 and it seems to work.

So chances are it's an issue with NAT on the ASA in front of the ZD it seems?

tony_heung

How about running capture command on both inside and outside interfaces on both ASA1 and ASA2 at the same time? So you can map on tcpdump to see if the L3 (ie: src/dst ip/port are expected ones) and the RADIUS payload is what you expected too (ie: NAS IP is nat'ed).

--tony

unknown

Tony,

Over the weekend I set my wireless at home to authenticate with the radius box at my office. I was able to see it come to the radius server using wireshark. However like you said the NAS ip is nat'ed. What type of NAT do I need to setup in order for this to work?

Thanks for your input

tony_heung

John, two possible ways you can experiment. First possibility is to allow all NAS ip as * on NPS so it does not matter if the NAS ip is nat'ed which is different from the originator ip. If it works, you will need to lock down the ACL and NAT rules on ASA to prevent unauthorised access. Second possibility is the put a destination NAT rule on the ASA (where the NPS terminated) so the source ip of the RADIUS packet would has the same source IP as if coming from the ZD, eg: ZD is 10.10.0.1, while your NPS side of the ASA would say the packet coming from the ZD would leave the ASA interface with 10.10.0.1 as the source ip replacing the public IP address of the ZD side of the ASA outside interface. But you need to have the corresponding rule on the NPS side of ASA so the return packet back to 10.10.0.1 will know the way back to the ZD via the ASA.

Final possibility to redesign the implementation is to create ipsec site to site tunnel between the two ASAs so RADIUS would just work.

Hope it helps.