access to management interface/network from VPN

[Freddy Andersen]

we have a ASA 5520 and vpn coming in to the inside which works fine. We also have our management interface that is connected to the same network that our ipml is connected to. How do we allow vpn users to get to this network?

interface Management0/0
 nameif mgmt
 security-level 100
 ip address 10.21.99.4 255.255.254.0 standby 10.21.99.5
!

Currently we get this:

Built local-host inside:10.21.99.92

Deny TCP (no connection) from 10.21.99.92/80 to 10.4.1.16/62348 flags SYN ACK  on interface inside

I thought this would help:

access-list nonat10 extended permit ip 10.4.1.0 255.255.255.0 10.21.98.0 255.255.254.0
access-list nonat10 extended permit ip 10.21.98.0 255.255.254.0 10.4.1.0 255.255.255.0
nat (inside) 0 access-list nonat10

but still the same. Is there something special with the management interface that can't be used this way?

[Marvin Rhoads]

The ASA will normally see traffic destined for the management interface as needing to "egress" to a connected interface. So, depending on how you have management access and routing setup, this may be tricky.

Fortunately, many others have done the same thing. Please have a look at this thread and also the one linked by Pete long to his blog. Let us know if that fixes you up.

[Freddy Andersen]

Hi Marvin,

So I'm looking at that but our firewall is only running 8.2.5 so we are in the before category and here is another datapoint when I'm on my vpn client pinging a node thats on the 'management' network I get that reply BUT when I do a telnet to port 80 I get a timeout? (which I see in the log for our ASA as a Deny on the way back)

So I'm sure there is either routing or some rule issue but I just don't understand what it is thats blocking this traffic. I did a packet-tracer and it says Deny but no good information there that I can make out.

[Marvin Rhoads]

Traffic comes in over VPN from the outside. You want the egress interface to be the inside but the ASA management interface being up on that network creates a connected route that will be the preferred path for the egress (all other things being equal). However, return traffic from the hosts on 10.21.99.0/23 network will egress their internal gateway and head back out to the ASA's inside interface - where there's no record of a TCP connection (or UDP flow) so it will fail.

I've had a similar situation once or twice before and was able to implement a work around by specifying a couple of static routes in the ASA pointing to the management network with a couple of longer prefix routes - e.g .two /24s in your case that cover the /23 (adding a couple of /32s for completeness of you need to reach the addresses equivalent to the broadcast and network numbers of the /24s).

With that in place, the ASA will properly choose the inside interface for egress of the traffic coming in from remote access VPN users and the return traffic should find the connection in the connection table and, since it is "interesting" to the cryptomap, encapsulate it for return over the VPN (while exempting it from NAT).

[Freddy Andersen]

Thank you everyone that looked at this issue BUT this was all me... 

I started looking at my logs and did not understand why the Deny TCP had a no connection.. then I figured it out... Our core router had a route back to the ASA for our VPN network but it was sending the traffic to the ASAs inside interface NOT the mgmt interface. This route is needed for all host on the inside to talk to our vpn clients so not sure how to fix this one other then remove mgmt interface from ASA.

Solution for now is to shutdown our mgmt interface and just add a route from inside to our core for the mgmt network.