Access Inside Gateway (ASA5505 v8.3)

[Atl_Gator]

Since we isolated the ARP-cache issue, our little ASA is rocking along (I'm starting to like the device! ) just like it should.

The issue I have now is a bit annoying, it's sort of the last issue:

  - Inside network:   10.0.0.0/24

  - Outside network:  XXX.XXX.184.144/24

  - VPN Pool:     10.0.1.0/24

The question is related to the VPN accessing the ASA itself.   We can access hosts within the inside network, and we can access the IP address on the outside network.  The Internet works fine (with full tunneling).

The issue is we can't get a connection to the ASA itself at 10.0.0.1 from a VPN connection on the subnet (example a VPN client at 10.0.1.151).  The VPN client is assigned a gateway IP of 10.0.1.1 but that IP doesn't respond either.   The ASA is accessible from anyone physically on the 10.0.0.0/24. 

We have pretty much all access rules open and here is the related nat objects:

inside-net = 10.0.0.0/24

vpn_users = 10.0.1.0/24

nat (inside,any) source static inside-net inside-net destination static vpn_users vpn_users

!

object network inside-net

nat (inside,outside) dynamic interface dns

object network vpn_users

nat (outside,outside) dynamic interface

gateway(config)#

Is there any way we can add a nat or a route that will give access to 10.0.0.1 from the VP (10.0.1.0/24) network?   Or make the 10.0.1.1

gateway actually connect to the ASA properly so that we can access the device over VPN?

[Jennifer Halim]

If you would like to get access to the ASA inside interface from the VPN, you need to add the following command:

management-access inside

[Atl_Gator]

Thanks so much for responding Jennifer.  Many of your other responses on this forum have been very helpful in learning the ASA.

We do already have this keyword defined actually and we can access the ASA from hosts on 10.0.0.1/24.  We can also install the client with https access on the outside.

The issue here is just to access the ASA from a VPN connection that is mapped to 10.0.1.151 for example (network 10.0.1.0/24).

We can't ping 10.0.0.1 or 10.0.1.1 (the gateway assigned to the VPN client).  However we can ping other hosts on the inside network from the VPN connection, for example 10.0.0.31.

I don't think, however, that we can access a 10.0.0.X IP address if it isn't NAT'ed out to an outside interface public IP.   I've tried all sorts of nat mixes and access rule mixes but nothing seems to work properly.

[Jennifer Halim]

From my understanding, you are trying to access the inside interface ip address of the ASA from the VPN connection. Is this a correct statement?

What is the inside interface ip address?

Also, I assume you are trying to ping, ssh, telnet, or asdm to this inside interface of the ASA from the VPN connection, is this correct?

Pls share the output of the following if the above is correct assumption:

sh run icmp

sh run telnet

sh run http

sh run ssh

[Atl_Gator]

Yep, you are correct!  Also want to use ASDM but I assume that is handled by http.

gateway(config)#

gateway(config)# sh run icmp

icmp unreachable rate-limit 1 burst-size 1

icmp permit any inside

icmp permit any outside

gateway(config)# sh run telnet

telnet 10.0.0.0 255.255.255.0 inside

telnet 10.0.1.0 255.255.255.0 inside

telnet 10.0.1.0 255.255.255.0 outside

telnet timeout 300

gateway(config)# sh run http

http server enable

http server idle-timeout 300

http 10.0.0.0 255.255.255.0 inside

http 10.0.1.0 255.255.255.0 outside

http 10.0.1.0 255.255.255.0 inside

gateway(config)# sh run ssh

ssh 10.0.0.0 255.255.255.0 inside

ssh 10.0.1.0 255.255.255.0 inside

ssh 10.0.1.0 255.255.255.0 outside

ssh timeout 60

gateway(config)#

Basically just want to access the ASA 5505 from a VPN connection that is on 10.0.0.1 and the VPN client IP address is 10.0.1.10 with gateway 10.0.1.1.

[Jennifer Halim · Accepted solution]

Base on the configuration above, you should be able to ping, ssh, telnet and http to the ASA inside interface.

Just want to confirm that the ASA inside interface is 10.0.0.1, and it has a subnet mask of 255.255.255.0, and similarly, the VPN assigned IP Address, if you can just double check, it is 10.0.1.10 and subnet mask is also 255.255.255.0.

You won't be able to access the VPN gateway ip address 10.0.1.1 as it is not a real gateway and not accessible. However, the inside interface of the ASA is definitely something that you can access via VPN.

[Atl_Gator]

Yep, I'm inclined to agree with you, however, sadly, no joy despite trying all kinds of things to get to 10.0.0.1 from the VPN network.

I attached:

  - Clip of logging file from a ping from the VPN client to 10.0.0.1

  - The full config (sanitized).

I am a bit stumped.  I'm guessing there is some line in there that shouldn't be there or a line that needs to be added but I've tried for a good

half day.  I think this is the last issue to make the device do and then we plan to lock it down (and will probably buy several of the more

expensive ones over next couple years).

[varrao · Accepted solution]

Could be possile that you are hitting this known issue:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtr16184

Can you verify it??

Thanks,

Varun

[Atl_Gator]

Not if I have to pay to do Q&A work for a Fortune 500 company!

Any chance you are willing to tell me what the bug is so I can at least rule it out and don't put any more hours into this?

[varrao · Accepted solution]

To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2.

Symptom: After upgrading the ASA to 8.4.2, all management traffic to-the-box(including icmp/telnet/ssh/ASDM) from hosts over the VPN (L2L or Remote ACcess VPN) may fail when destined to the management-access interface IP address.Conditions: 1. Issue is observed if ASA is on 8.4.2. Not observed on 8.4.1. 2. Users directly connected to the internal interfaces face no issues with icmp/telnet/ssh/asdm to their respective interfaces.Workaround: The problem can be traced to a Manual NAT statement that overlaps with the management-access interface IP address. The NAT statement must have both the source and destination fields. Adding the "route-lookup" keyword at the end of the NAT statement resolves the issue.Ex: ASA's Management-Access Interface IP address is 192.168.1.1.! Overlapping NAT statement: nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-vpn obj-vpn! New Statement: nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-vpn obj-vpn route-lookup

[Atl_Gator]

Bingo!  You nailed it.  Works great now.  Need to lock stuff down tomorrow security wise and I think we are golden.

For the stuff that worked and things, I did have a lot of fun with it.  It's a cool device.

5 stars for both of you!