ASA/ASDM assistance requested

So, not being a networking guy (casually working towards a CCNA for fun), I'm stumped with this ASA/ASDM issue. My current customer has two separate sites, one called HQ and one DR. Here are the facts:

While on the HQ LAN I can access resources at DR
While connected via VPN (Cisco through ASA firewall) I cannot access resources at DR
I can ping/traceroute via ASDM (version 7.1) to DR resources via it's 'server-core' interface (which is how it's configured for other offices in the network, office synonymous with site for this exercise but they differ in purpose)
The VPN IPv4 address assignment to client connections (AKA me off-site) is on the same subnet as the 'server-core' interface
DNS lookup is enabled on 'server-core' interface so DNS resolves correctly
ACL's for 'VPN_ACCESS' specify any/any permitted via IP
I added a static route for troubleshooting purposes that matches the other offices (interface and gateway, obviously IP address would be different [would gateway too if this is a different connection {MPLS to DR site}?])
When I tracert from my off-site VPN-connected desktop, it tries to hit the public IP of the ASA first hop. Super weird.

So yeah, nowhere near a networking guy. I understand things from an internal perspective (I'm an infra engi) but once you jump outside that I start losing speed. However, my gut has been a routing issue.

TIA

For example reference
HQ 10.10.0.0/16
DR 10.20.0.0/16

First thought...is this an EIGRP issue with the MPLS cloud? I feel like a dummy trying to talk about networking protocols

Find more posts tagged with

Comments

Kreken

lsud00d wrote: »

While on the HQ LAN I can access resources at DR

While connected via VPN (Cisco through ASA firewall) I cannot access resources at DR

If in the second bullet, you are talking about remote access VPN then you need to enable intra-interface traffic on outside interface aka hairpinning.

lsud00d

You are correct, and as I re-read it I see that I did not make that my point...I am unable to access resources at the DR site via VPN.

That's interesting, I haven't heard about hairpinning before. I just read up on it and it seems pretty straightforward...since I already have the network objects defined I just have to create a NAT? I was even leaning that way during the troubleshooting...

Kreken

You don't need NAT, since your VPN IP pool is already a part of the internal network. Right? So it will be included in the encryption domain aka interesting traffic. All you need to do is enable intra-interface traffic. In ASDM, go to Configuration, Device Setup and Interfaces. On the bottom put a check mark next "Enable traffic between two or more hosts connected to the same interface".

lsud00d

Kreken wrote: »

your VPN IP pool is already a part of the internal network. Right? .

This is correct. I was asking about the NAT because I was referring to this:

https://supportforums.cisco.com/discussion/11293006/help-please-vpn-anyconnect-hairpinning-configuration

I did create a NAT as suggested above but no dice. To further clarify the example addressing:

HQ 10.10.0.0/16
HQ VPN IP Pool 10.10.10.25-35
DR 10.20.0.0/16

The /16 is obviously a sweeping generalization, the private networks aren't that large but they are VLAN'd across /24's so there are more than a handful...

I found the setting you suggested (thanks!), are there any general implications for enabling it?

Update: I read more on intra-interface same security traffic and didn't see any harm in temporarily enabling it. However, I was still unable to resolve to the DR network. Kinda puzzled as I tried both this and the NAT--

nat (SERVER-CORE,OUTSIDE) source static Internal-Subnets Internal-Subnets destination static OBJ-IP-POOL OBJ-IP-POOL no-proxy-arp

Any other ideas?

Kreken

I am not really aware of any implications. I have been using this in my environment for a long time without issues. Even during external security audits, it never raised a red flag.

lsud00d

After reading more I've disabled the changes I made (NAT & intra-interface same security traffic) to avoid asymmetric routing...not that I think it would occur but this is the main firewall and I don't want any packets losing their way

Kreken

There is a troubleshooting tool built into ASA IOS called the packet tracer. You can use it to see what happens to the packet and if and where it is dropped.

Without knowing your topology but going on from your previous posts, I highly doubt it would create an asymmetric routing.