using ASA as default gw/router

[tato386]

I have an MPLS router on the same LAN subnet as my ASA which is also my default gateway.  I have a couple remote subnets that are reachable via the MPLS.  On the other side of the MPLS I have an identical environment with ASA as default gateway.

I have applied all the techniques that I have found under "hairpining or u-turn" for ASA including TCP-Bypass and identity NAT and I am having some success but not quite 100%.

What is happening is that I can establish TCP connections LAN-to-LAN across the MPLS such as telnet and http but not any ICMP based connections such as ping and traceroute. This was quite frustrating because my initial tests with pings and traceroutes had me thinking it was not working at all.  During the troubleshooting process I opened a browser and connected across the MPLS and realized I had partial connectivity.

When I test with packet tracer I get confusing results.  The packet tracer utility tells me echo should work but they are not.  The packer tracer tells me that traceroute should fail but I can't tell which rule or feature is blocking it.

Any and all ideas are welcome.

TIA,
Diego

[Vibhor Amrodia]

Hi,

Have you tried to disable the ICMP inspection from both the ASA devices ?

Can you share some more outputs from the ASA device ?

Thanks and Regards,

Vibhor Amodia

[tato386]

I have tried with inspect ICMP and inspect ICMP Error both enabled and disabled and it doesn't seem to make a difference.  Also added the noproxyarp command on inside interface with no luck.  Still no ICMP but TCP connections OK.  In the logs I see the ICMP being denied but can't figure out what is causing it.

4

Oct 11 2014

20:54:45

Denied ICMP type=0, from laddr 192.168.2.3 on interface inf_data to 192.168.1.16: no matching session

[david-swope]

Ok, as I understand this, you cannot ping or traceroute through the ASA? You will want to inspect ICMP on both ASA's? You will need to create a few ACL's as well and if you want the ASA to show up in the path, add a new class inspection. This can easily be found via google

icmp unreachable rate-limit 10 burst-size 5

access-list outside_in extended permit icmp any any time-exceeded 
access-list outside_in extended permit icmp any any unreachable

access-group outside_in in interface outside

policy-map global_policy
class inspection_default

class class-default
set connection decrement-ttl

Give that a shot

[tato386]

I am not trying to go _thru_ the ASA.  The traffic enters and leaves (hairpins, u-turns) using the ASA inside interface, never crossing the ASA.  For example, the ASA is 192.168.1.1 and has a static route to 192.168.2.0/24 via 192.168.1.2.  Clients on the 192.168.1.0/24 network use the ASA as default gateway.  I have the same setup on the 192.168.2.0/24 network with default gateway is the ASA at 192.168.2.1 and route to 192.168.1.0/24 via 192.168.2.2.

TCP traffic from clients on the two subnets is working.  ICMP does not.  Currently I am inspecting ICMP and ICMP error.

[Marius Gunnerud]

what are the security levels on the two interfaces?

I assume you have the command same-security-traffic permit intra-interface command configured on the ASA?

Also, make sure that the software firewall on the PC's (ie. windows firewall) is turned off or at least permits ICMP, otherwise you will get a failed result.

--

Please remember to select a correct answer and rate helpful posts

[tato386]

Hi Marius:

I am hairpining traffic on the same interface.  Traffic comes in and out on the same interface which is my inside int with security level 100. But yes, I use permit same-security command and all devices have their firewalls turned off.

Thanks,

Diego

[Marius Gunnerud]

It would really help to see the running configuration of the ASA, and perhaps a network diagram.

Do you have subinterfaces configured on the ASA for different VLANs or is it just the one physical interface?

Do you have NAT configured on the ASA for the traffic in question?  If so are you NATing specific ports or doing full 1 to 1 NAT.  If you are NATing specific ports then you would also need to NAT ICMP for the host IPs.

--

Please remember to select a correct answer and rate helpful posts

[tato386]

Here you are sir.  I tried to be as detailed as possible.  Note that I am just testing Data-A to Data-B at the moment.  which I figured would be slightly easier to get going. I haven't tried anything on the voice subnet yet.

Thanks,

Diego

[david-swope]

I see you are performing TCP-Bypass on all private segments. If that is so, having inspect ICMP makes no difference since you are bypassing stateful inspection. 

Post a "sh conn" from each ASA as well, we should see connections that are bypassed flagged with a "b"

Also, maybe you did it will sanitizing your config but Site-B ASA has no trunk or access port for VLAN 1

Your previous error  "no matching session" leads me to think asymmetric routing could be occurring, but having tcp_bypass should avoid this since we aren't inspecting or looking at the stateful database for connections. What do traceroutes look like? 

The thing is, since we are bypassing stateful inspection, we need to have ACL's that allow what we want (ICMP), this should be your tcp_bypass traffic. And where is your service-policy showing which interface/s you have assigned tcp bypass to?

I would recommend creating new policy-map for your bypass, makes it cleaner to troubleshoot and keeps it out of global_policy.

i.e.,

class-map tcp_bypass

  match access-list tcp_Bypass_acl

policy-map Bypass-Policy

  class tcp_bypass

  set connection timeout idle 0:10:00

  set connection advanced-options tcp-state-bypass

service-policy Bypass-Policy interface “interface_name”

[Marius Gunnerud]

The error message you posted earlier indicated the following:

Denied ICMP type=0, from laddr 192.168.2.3 on interface inf_data to 192.168.1.16: no matching session

However, in your diagram and in your configuration Data A is on 192.168.0.0/24 and Data B is on 192.168.1.0/24.  Your error message is referencing an IP on 192.168.2.3? where is this IP located?

--

Please remember to select a correct answer and rate helpful posts

[tato386]

Yeah, that is weird. I don't know where the 192.168.2.3 address came from.  I just tested again and have attached samples.  It is clear that the remote ASA blocks the reply to the ping because it didn't pass thru the ASA (came from the MPLS router) and therefore there is no session.  But since ICMP inspection is turned off it shouldn't be doing this.  I guess maybe a bug?

[tato386]

Thanks,

Diego