Connections routing between two internal ASA's fail

Answered Question
May 20th, 2012

Hello All,

I have a problem that I can not fix.  We have a site with two inbound circuits, one for internet and one for our MPLS.  Each circuit is being terminated by a 2921 Router and matching ASA 5510 Firewall.  For the internal network, the Internet ASA's inside interface (172.16.0.1) is the default gateway for all hosts.  OSPF is the routing protocol between all the routers and ASA's and routing is working.  In fact, ICMP is working as well.  From an inside host (172.16.0.81), we can ping anything on the MPLS network.  But when I try to use telnet (for example), the connection fails.  If I add a route to 10.10.10.0 to the host, or re-configure the host to point to the MPLS ASA (172.16.0.254) as it's default gateway, connections will establish.

Connection Problems.jpg

Both ASAs are running 8.4(3), and have the following commands:

same-security-traffic permit intra-interface

interface Ethernet0/0

nameif outside

security-level 0

interface Ethernet0/1.1

vlan 10

nameif inside

security-level 100

And for now, and for testing, the MPLS ASA has this Access-List:

access-list Outside_ACL extended permit ip any any

What I have found is this, if we point directly to the MPLS ASA, connections are created successfully.  When poining to the Internet ASA, only ping works and all other connection types fail to succeed (at lease TCP, have not tried udp applications).  If looking on both ASA's, i see a connection made:

ASA01# show conn all

TCP inside 10.10.10.10:443 inside 172.16.0.81:56192, idle 0:00:02, bytes 0, flags SaAB

And from the MPLS nodes, I can see a tcp request is made.  So i'm guessing the problem is between the ASA's?

What am I missing? 

Thanks for any help,

Nick

I have this problem too.
0 votes
Correct Answer by marcel.verbruggen about 1 year 11 months ago

You have asymmetric routing in your network, which is not supported with ASA firewalls.

On the way to the remote site, the packet will travel:

Host -> Internet ASA -> MPLS ASA -> MPLS router -> remote host.

But since the inside interface of the MPLS ASA is in the same subnet as the host, the packet back travels:

remote host -> MPLS router -> MPLS ASA -> host. (It skips the internet ASA).

Since the connection to the MPLS ASA was orignally build from the internet ASA, this will fail.

Ping is not a 3-way handshake, but rather the echo and echo reply are 2 seperate flows. The ASA does not by default build a connection for that (it only does if you enable ICMP inspection). Therefor ping will work. UDP will also work because of the same reason.

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
ju_mobile Sun, 05/20/2012 - 14:55

Hi Nick,

My assumption is that you have a single site with dual connections. Please can you confirm the routing in those LANs and specifically the default route? You have highlighted the issue. However, you may need to furnish some detailed information to show the existing implementation

Sent from Cisco Technical Support iPad App

nickhesson Sun, 05/20/2012 - 15:45

No assumptions are needed, what we have is exactly what is in the shown inserted image.  Without a doubt routing is working, because if it wasn't.  Ping would also fail.  But we can ping fine.  What would a default route have anything to do with this problem? 

What details would be needed?  Again, the remote MPLS nodes are recieving connections from this site.  Something is failing between both ASA's or the traffic in and out of this site.  That is proventing the connection to establish all the way.

Nick

ju_mobile Mon, 05/21/2012 - 16:09

Apologies,

I can't see any image may be my device. You highlighted and I don't know your network so have to either make an assumption or ask further questions.

We have a site with two inbound circuits, one for internet and one for our MPLS. Each circuit is being terminated by a 2921 Router and matching ASA 5510 Firewall.

So my assumption is that you have a single site with an internet connection and interconnect back into the wan.

Wan----router-5510---local lan---5510--router--

www is my assumption correct?

172.16.0.0

Are you running single or multiple ospf instances ?

If you add a static route via the wan asa your telnet works. Smells like the traffics hitting the wrong firewall.

Have you run a debug to verify if that is the case or do you see the deny in your logs on the wan firewall?

nickhesson Tue, 05/22/2012 - 17:49

Sorry Ju_Moblie,

I do appreciate the attempt to help.  But if you read the whole post, you will see that we're getting connection attempts at the device on the MPLS network.  Futhermore, if routing was the issue, Pings would also fail!!!  So Once and for all, Routing is not the issue. 

I see the traffic pass over both internet and MPLS ASAs, and hit the device on the MPLS side.  But the connection never finishes and ICMP works fine. 

Can anyone else that can see the image, possibly get me a clue? 

Thanks for your time and help,

Correct Answer
marcel.verbruggen Wed, 05/23/2012 - 00:34

You have asymmetric routing in your network, which is not supported with ASA firewalls.

On the way to the remote site, the packet will travel:

Host -> Internet ASA -> MPLS ASA -> MPLS router -> remote host.

But since the inside interface of the MPLS ASA is in the same subnet as the host, the packet back travels:

remote host -> MPLS router -> MPLS ASA -> host. (It skips the internet ASA).

Since the connection to the MPLS ASA was orignally build from the internet ASA, this will fail.

Ping is not a 3-way handshake, but rather the echo and echo reply are 2 seperate flows. The ASA does not by default build a connection for that (it only does if you enable ICMP inspection). Therefor ping will work. UDP will also work because of the same reason.

nickhesson Wed, 05/23/2012 - 13:40

THANK YOU! 

That fixed the problem!  All anyone would have to tell me was asymmetric routing.  Below fixed my problem:

access-list MPLS_IN extended permit ip 172.16.0.0 255.255.0.0 10.10.0.0 255.255.0.0

class-map MPLS_IN

match access-list MPLS_IN

policy-map MPLS_IN

class MPLS_IN

set connection advanced-options tcp-state-bypass

service-policy MPLS_IN interface inside

Thanks again,

Nick

Actions

Login or Register to take actions

This Discussion

Posted May 20, 2012 at 12:43 PM
Stats:
Replies:6 Avg. Rating:5
Views:865 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 7,861
2 6,140
3 3,170
4 1,473
5 1,446