cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
587
Views
0
Helpful
4
Replies

Traffic across VTI doesn't work correctly for RADIUS

MP13
Level 1
Level 1

This is related to the below previous post:

https://community.cisco.com/t5/network-security/raidus-fails-post-upgrade/m-p/4971069#M1106508

I have an issue where the connection to RADIUS will work as far as hitting the RADIUS server and triggering the MFA prompt from Azure AD however after approving it my authentication requests are always discarded. The discard is reported to be by the DLL responsible for Azure MFA however in the Azure MFA logs it shows it as accepted.

If I trace the traffic it also appears to try and send the request back however the traffic is coming from the VTI IP rather than the inside interface and I don't believe a VM in Azure can route back to this VTI IP because of some of the restrictions that Azure has in place.

If I change the RADIUS connection to be set to the inside interface rather than using route lookups then the traffic never makes it to the NPS. If I run a packet trace though the final result appears correct:

Result:
input-interface: inside(vrfid:0)
input-status: up
input-line-status: up
output-interface: azure-vti(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 653161 ns

I'm unsure if this is related but if I ping from the firepower without specifying an interface it times out however if I specify the interface it works correctly.

ping 10.10.9.4
Please use 'CTRL+C' to cancel/abort...
Sending 5, 100-byte ICMP Echos to 10.10.9.4, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

ping interface inside 10.10.9.4
Please use 'CTRL+C' to cancel/abort...
Sending 5, 100-byte ICMP Echos to 10.10.9.4, timeout is 2 seconds:
!!!!!

I've tried various static route combinations and forwarding via another device etc but I can't get it to work. Prior to applying the latest patch this worked without any issue.

If I run the test from RADIUS then it comes from the management IP and that all works correctly with the MFA prompt and says success in the FDM after approving it. It's only when I try to do it in production either leaving it to be route based or specifying from the inside interface that I get issues.

I did also see a recommendation to use the diagnostic interface which I configured but couldn't seem to get any response from that either.

1 Accepted Solution

Accepted Solutions

MP13
Level 1
Level 1

In the end I upgraded to 7.4.1-172 and on that version the management and diagnostic interfaces can be merged. Once merged I then set the source interface for RADIUS to the management interface and now everything works properly again.

View solution in original post

4 Replies 4

Ruben Cocheno
Spotlight
Spotlight

@MP13 

I had those issues in the past, the only way to make it work was using the inside interface facing the NPS locally since you can't specify the source of radius requests, the firewall takes the shortest path and uses that interface. I've tried to use the management interface but somehow never worked properly since traffic was not leaving the correct interface.

Perhaps SAML with Azure AD might be a suitable option.

I hope it helps.

Tag me to follow up.
Please mark it as Helpful and/or Solution Accepted if that is the case. Thanks for making Engineering easy again.
Connect with me for more on Linkedin https://www.linkedin.com/in/rubencocheno/

Isn't the interface specified in the RAIDUS server configuration the one that it should use though? The firewall taking the shortest path and using that interface I would only expect if I was using the resolve via route lookup option.

SAML with Azure AD is an option and one I've tried as I saw it now as an option in the version we upgraded to but I had issues getting it to work. I've set it up numerous times on ASA image without issue but on FDM I get issues which seem like the URL's may be different from ASA however the ones in the documentation give me the same issue. 

I've given it another test just now and the error returned for SAML is "Wrong URL" returned from "https://___._____________.com/+CSCOE+/message.html?mc=2"

URL's set are below which is what we use on ASA:

Identifier: https://___._____________.com/saml/sp/metadata/VPN-TEST
Reply URL: https://___._____________.com/+CSCOE+/saml/sp/acs?tgname=VPN-TEST

I had a bit more of a look into the Azure SAML issue and it seems when I try to authenticate or even update the configuration in the debug logs I get "SAML config was not found".

If I do "show saml metadata VPN-TEST" I also get nothing.

I've seen a couple of suggestions which are similar to the old ASA issue of having to turn the IDP off and on again against the profile after making changes so I've given that a go but it just logs the same SAML config was not found message on each update.

MP13
Level 1
Level 1

In the end I upgraded to 7.4.1-172 and on that version the management and diagnostic interfaces can be merged. Once merged I then set the source interface for RADIUS to the management interface and now everything works properly again.

Review Cisco Networking for a $25 gift card