cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

1291
Views
0
Helpful
3
Replies
Highlighted
Beginner

ICMP issue with asymmetric routing

Hi everyone

Hope you can help me with this issue.

I set up an ASA5516X in a network that has asymmetric routing, but now we are having issues with ICMP and a XMPP app. I'm asuming that both symptoms occur for the same reason.

The internet connection is attached to our ASA, but we have a data connection with a remote office that arrive directly to the local network. Default gateway for Server XMPP is the ASA, when we ping from the server to the PC on the remote office there is no problem with it, however, when we ping from the remote PC to the Server, the ASA seems to be blocking the icmp reply from the Server.

We already configure TCP-state-bypass on the ASA, enable ICMP inspection on a policy-map and allow communication inter-interface

We did some captures on the ASA, receiving this output

ciscoasa(config-pmap-c)# capture PING interface inside real-time

Warning: using this option with a slow console connection may
result in an excessive amount of non-displayed packets
due to performance limitations.

Use ctrl-c to terminate real-time capture


1: 04:06:25.634183 arp who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.50
2: 04:06:25.644116 arp reply 192.168.1.254 is-at 0:0:ab:3b:c0:0
3: 04:06:27.166602 arp who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.50
4: 04:06:27.176626 arp reply 192.168.1.254 is-at 0:0:ab:3b:c0:0
5: 04:06:28.274201 arp who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.50
6: 04:06:28.284256 arp reply 192.168.1.254 is-at 0:0:ab:3b:c0:0
7: 04:06:29.553544 192.168.1.50 > 192.168.2.2: icmp: echo reply
8: 04:06:31.011336 192.168.1.50 > 192.168.2.2: icmp: echo reply
9: 04:06:33.838823 192.168.1.50 > 192.168.2.2: icmp: echo reply
10: 04:06:37.023085 192.168.1.50 > 192.168.2.2: icmp: echo reply

(this is when we ping from the remote PC, when we ping from the local lan to the remote office we receive this output

ciscoasa(config-pmap-c)# capture PING interface inside real-time

Warning: using this option with a slow console connection may
result in an excessive amount of non-displayed packets
due to performance limitations.

Use ctrl-c to terminate real-time capture


1: 04:08:26.833483 802.3 encap packet
2: 04:08:28.355526 192.168.1.50 > 192.168.2.2: icmp: echo request
3: 04:08:28.356381 192.168.1.50 > 192.168.2.2: icmp: echo request
4: 04:08:29.888473 192.168.1.50 > 192.168.2.2: icmp: echo request
5: 04:08:29.889282 192.168.1.50 > 192.168.2.2: icmp: echo request
6: 04:08:31.422707 192.168.1.50 > 192.168.2.2: icmp: echo request
7: 04:08:31.423531 192.168.1.50 > 192.168.2.2: icmp: echo request
8: 04:08:32.982874 192.168.1.50 > 192.168.2.2: icmp: echo request
9: 04:08:32.983698 192.168.1.50 > 192.168.2.2: icmp: echo request
10: 04:08:34.560395 192.168.1.50 > 192.168.2.2: icmp: echo request
11: 04:08:34.561158 192.168.1.50 > 192.168.2.2: icmp: echo request

Is there any issue with asymmetric routing that is impacting the icmp packets and xmpp connectiongs?

Note: We replicate the scenario in GNS3 as we have limited access to the functional ASA

Best regards

Everyone's tags (4)
3 REPLIES 3
Highlighted
Advisor

Add a route on the XMPP

Add a route on the XMPP server to go via R1 for the remote network.

Highlighted
Beginner

We already test to set the

We already test to set the default Gateway of the XMPP server as R1, in that configuration PC and server can ping between them. But the XMPP service does not goes up.

We beleive that the server only negotiate the connection between hosts and then it create a p2p connection between them. My best choice is to change the default gateway of all the devices on the network to R1.

But before we do that, we need to exhaust all other possible solutions.

Regards

Highlighted
Advisor

Don't change the default

Don't change the default route - just an an extra network route on the XMPP server for the remote subnet going via R1.