02-20-2015 12:19 PM - edited 03-11-2019 10:32 PM
OM-ASA (1) = 192.168.1.0 MPLS Gateway = 192.168.1.253
BA-ASA (2) = 192.168.2.0 MPLS Gateway = 192.168.2.253
Using version ASA 8.2 with TCP State bypass, I cannot ping from 192.168.2.0/24 to 192.168.1.0/24 and vice versa, with the exception I can ping the gateway on both, in other words, I can ping 192.168.2.1 from any 192.168.1.0/24 and I can ping 192.168.1.1 from any 192.168.2.0/24
I enabled ICMP inspection for the Global Policy Map, I thought this would apply to all interfaces.
I can ping from both to Outside, no problem. Just cannot ping LAN to LAN.
02-20-2015 01:30 PM
on ASA om
no route inside ba-net 255.255.255.0 om-mpls 1
on ASA BA
no route inside om-net 255.255.255.0 ba-gw 1
The ASAs should "try" to reach these networks through the outside in order to activate the crypto map
Also your crypto access-lists are not telling your firewall to encrypt the traffic you want.
That's what you have
access-list outside_1_cryptomap extended permit ip 192.168.2.0 255.255.255.0 ml-net 255.255.255.0
access-list outside_2_cryptomap extended permit ip 192.168.2.0 255.255.255.0 ev-net 255.255.255.0
you need 192.168.2.0 to om-net (192.168.1.0/24)
You can create a new crypto map sequence and use a new access list, mathing this traffic.
02-20-2015 01:43 PM
Guibarati - Thank you for your response.
Actually, I am not using VPN tunnel for the 2.0 to 1.0 (and vice versa), the tunnel I have listed are for different subnets,, sorry for the confusion.
For the subnets in question I am using static routes that point to our MPLS gateway.
I'm think I need to create an ACL to permit ICMP inside but I thought the global inspection engine did this already
02-20-2015 01:50 PM
You are right,
You need to add it to the ACL.
When you have it in global inspection it will allow the "returning" packet.
In your case, because it's asymmetric the ASA doesn't see the incoming packet. it only sees it on it's way out and blocks it because there was no original packet.
it goes like
host-> ASA1-> back to mpls_router----other_mpls--->host--->ASA2
when it hits ASA 2 it had never seen the 1st packet coming to allow the return.
Also, for the ASA1 to route it back through it's inside interface it needs to be allowed on the ACL on the first place.
The tcp bypass should't influence on the ping (since it's not TCP), but you will need it for TCP applications.
02-20-2015 02:04 PM
Thanks Guibarati that makes sense. How does the below look?
om-asa
access-list 101 extended permit icmp any ba-net 255.255.255.0
access-list 101 extended permit ip any any (do I need this line? last time I tried without seemed I lost Internet access)
access-group 101 in interface inside
ba-asa
same as above just reverse first line
Thanks a million.
02-20-2015 02:08 PM
Yes, that's the access-list you need.
02-20-2015 02:31 PM
Sorry to be a pest. I added the ACL to both ASA's, doubled checked for typos. Still I am not able to Ping LAN to LAN.
02-20-2015 02:35 PM
02-20-2015 02:55 PM
Try using ASDM logging and filter the IP you want to see to check if ASA is denying it for some reason.
In reality I would point the MPLS router as default gateway for the stations and have it point back to the ASA the necessary routes.
The router can generate icmp redirect, so if the host goes to the router and the router routes the traffic back to the ASA, the router will instruct the host to go ot the ASA directly for that host, automatically. this automatic route expires after a while and the router does it again. (or you can just leave the router re-routing it.)
If you can't do it.. let's see what ASDM says.
02-22-2015 01:59 PM
It is saying ICMP is denied. I believe it has to do with me using the TCP State Bypass rule for traffic from the BA-Net to the OM-Net and vice-versa. I'm beginning to wonder if pinging is even possible in this setup.
02-22-2015 02:28 PM
Turning the ICMP inspection off seems to have solved my "ping" problem. Please see number 4. Thanks very much for all your help.
1. Note that, as the name suggests, TCP State Bypass can be used to resolve such asymmetric routing issues only for TCP traffic and nothing else.
2. For example, pings from 192.168.1.x to 192.168.2.x may work; but pings initiated from 192.168.2.x to 192.168.1.x will not. This is because the ASA is usually configured to inspect protocols such as ICMP (refer:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008085283d.shtml
3. Thus, when initiating pings from 192.168.2.x to 192.168.1.x, the echo request reaches 1.x directly through the router whereas the echo reply from 1.x is sent to the ASA. Since the ASA is unaware of this ICMP session, it simply drops the echo reply packet.
4. The only workaround to allow pings to work from 192.168.2.x to 192.168.1.x is to disable ICMP inspection for that traffic on the ASA.
5. The same holds true for other protocols that are being inspected by the ASA.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide