cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1566
Views
5
Helpful
14
Replies

RAIDUS Fails Post Upgrade

MP13
Level 1
Level 1

Hi,
Over the weekend we have upgraded a Firepower 1010 to 7.2.5.1-29 from 7.2.5-208 and since then RADIUS has stopped working for our remote access VPN.

The NPS server sits in Azure so we have a tunnel between the Firepower and Azure and all is working fine with traffic passing and other functions working as they should.

If we run the test from the identity sources configuration page it also works except it comes from the management interface IP but if we update the NPS to accept that as a client it passes fine.

In the identity sources configuration we have it set to use the inside interface as the source. Once we try to connect the remote access VPN the request never reaches the NPS server in Azure despite that the test function worked albeit on a different IP/interface. We've run Wireshark to validate that the traffic never makes it there as well.

Packet tracer doesn't appear to show any issues either and shows as though it should go via the ipsec-tunnel. 

I've tried doing a packet capture from the CLI as well but whatever method I tried I didn't get any packets matched.

I'm not really sure why it would have stopped working with this patch, as it's been working for a number of months prior. Are there any suggestions on what I can check or try or is there a way to rollback the patch?

1 Accepted Solution

Accepted Solutions

We use unnat when traffic IN go OUT and we have NAT apply to OUT

Here with route based VPN 

Traffic IN go VTI and there is no NAT in VTI.

What happened the traffic route based on noNAT not based on RIB.

MHM

View solution in original post

14 Replies 14

So you config management access for interface you use to connect to radius over s2s vpn?

MHM

As far as I'm aware you can only do that for HTTPS and SSH connections but not RA-VPN. Or at least in the management access section those are the only 2 options.

When we set this up originally we had to create a flex config object with "management-access inside" and after that it worked and that command is still in effect post upgrade.

https://bst.cisco.com/bugsearch/bug/CSCvg50549

Check this bug and workaround of it

MHM

Thank you, however this doesn't appear to be applicable in our scenario. The closest I can do is setting the source interface of the RADIUS connection to be from the outside interface which I gave a try just in case however that doesn't work as it then sources it from the public IP. 

In the workaround the reason that works is because with the commands like http, ssh, snmp-server, etc although you specify the outside interface you are also specifying the IP from which it should work however in the case of RADIUS it's specifying the source interface to use to communicate.

In the workaround they also show that they are getting drops however in our case packet-tracer shows that things are passed. Unfortunately I couldn't get an actual packet capture to work to properly verify this though.

One other thing I did start trying as well was a route based VPN as I wondered with it properly in the routing table and the RADIUS connection set to use routes lookup instead whether that would work however once I established the VPN I could only get it to work from Azure to the Firepower and traffic from the Firepower to Azure failed. It came up with suboptimal route lookup and then resorted to using the public gateway instead. Posting this here in case that's another option that it may be worth resolving as at the moment I put it back to policy based.

Phase: 14
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Elapsed time: 465 ns
Config:
Additional Information:
Input route lookup returned ifc azure-vpn-vti is not same as existing ifc outside
Doing adjacency lookup on existing ifc outside

Phase: 15
Type: NEXTHOP-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Lookup Nexthop on interface
Result: ALLOW
Elapsed time: 1860 ns
Config:
Additional Information:
Found next-hop 91.X.X.1 using egress ifc outside(vrfid:0)

MP13
Level 1
Level 1

Just as another test I found some people were suggesting that to perform RADIUS over VPN you should use the diagnostic interface so I've added another subnet to that and added it to the traffic selectors for the VPN and can see an SA for it in Azure however traffic fails to pass on it. 

Packet-tracer shows "Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x0000564fd8242788 flow (NA)/NA" even though I've allowed traffic to and from the diagnostic subnet. 

SUBOPTIMAL-LOOKUP

This issue come from NAT lookup' so your no-nat of ipsec vpn do NAT lookup or not?

Also share 

Show route management only 

Let see the route in this table.

MHM

Output of show route management-only is below however this only relates to since we tried to configure the diagnostic interface this morning. Otherwise we've always specified the inside interface to be used in RADIUS. The SUBOPTIMAL-LOOKUP was from when we tried to move to route based VPN which we did not use previously. Currently we have it configured back to using policy based VPN.
 
C        10.10.13.0 255.255.255.0 is directly connected, diagnostic
L        10.10.13.1 255.255.255.255 is directly connected, diagnostic

If management access is OK the inside interface must appear in table.

I still thinking it issue that mgmt-access not work.

For workaround for bug I share before' indeed we use outside but see the acl of vpn it have new entry which have permit  host OUT to host Radius

MHM

There are a few different scenarios in my details though.

1) Access from inside interface which worked for many months prior to the update. Packet tracer shows this passing correctly but the traffic never makes it over the VPN.

2) Attempt to configure routed VPN instead of policy VPN for which the SUBOPTIMAL-LOOKUP relates to so traffic ends up getting sent to WAN rather than through the VTI that's set in the static route. 

3) Attempt to use the diagnostic interface to which the route information for management-only relates to. This us what shows in packet tracer as the ACL drop.

2) Attempt to configure routed VPN instead of policy VPN for which the SUBOPTIMAL-LOOKUP relates to so traffic ends up getting sent to WAN rather than through the VTI that's set in the static route. 

This solution' as I mentioned suboptimal is cause by NAT' do you config NAT? If yes why you need NAT? 

NAT need only for policy based VPN 

MHM

We configured an UN-NAT policy for the traffic I think just out of habit. Should we remove this?

We use unnat when traffic IN go OUT and we have NAT apply to OUT

Here with route based VPN 

Traffic IN go VTI and there is no NAT in VTI.

What happened the traffic route based on noNAT not based on RIB.

MHM

Thanks. I think it was actually there because we moved from policy based to route based so that's what threw things. I've removed that rule and traffic now works in both directions on the route based VPN. It did then fail RADIUS still but at least I got traffic which showed me the failure was just as the source changed to the VTI.

Updated the policy to the VTI IP and all works again now.

Thank you!

You are so welcome 

Glad your issue solved 

Have a nice day 

MHM

 

Review Cisco Networking for a $25 gift card