Multiple internal interfaces stopping traffic from DMZ

[paul.smith]

I recently added a backup internal interface using IP SLA to cutover our inside interface in the event that our internet gateway crashes.  I'm also attempting to route all traffic from the internal network to the DMZ over this backup internal interface since there is no need to filter anything bound for the DMZ through this internet gateway(firewall rules do that already).

Here's the basic setup:

ASA 5520

Inside1 (10.5.5.1/29) ---->Transparent Bridge [Internet Gateway] (10.5.5.2/29) Internal core switch (10.5.5.3/29)

Inside 2 (10.5.5.9/29) ----> Internal core switch (10.5.5.11/29)

DMZ (192.168.9.1/24)

The ASA has routes with a metric of 1 (track 1) that point all subnets to 10.5.5.3 (Inside1)

The ASA has routes with a metric of 5 that point all subnets to 10.5.5.11 (Inside2) in the event the ping to 10.5.5.3 fails

The Internal core switch has a default route pointing to 10.5.5.1 (inside1)

The Internal core switch also has a route for 192.168.9.0/24 (DMZ) to go out inside2 (10.5.5.9)

The Internal core switch also has IP SLA stuff similiar to the ASA that changes the default route to 10.5.5.9 in the event of a failure on Inside1.

The security level of the inside interfaces is 100 and allow communications between same security level is active.  The DMZ is security level 50 and NAT exemptions are in place for both inside interfaces to enter the DMZ.

So everything works well unless a session gets initiated from inside the dmz to the internal network (the other way around works just fine).  I can ping from the DMZ to inside, but any TCP session I believe doesn't receive ACKs and the session just hangs and times out.  My guess being that traffic from the DMZ is going out Inside1 but trying to come back in Inside2?  Any ideas how to go about fixing this and is it even possible without PBR on the ASA?

Many thanks

-Paul

[jocamare · Accepted solution]

The problem might somehow be related to asymetric routing, if ping works, the rest should work too.

We can confirm or discard this with packet captures on the inside2 interface when sending traffic between the DMZ and inside.

Also, can you share your nat configuration from the asa? Maybe the complete configuration?

Try to get the output of the "show local details" while testing, and also if there is no much traffic flowing across the unit, try to also get the "show local details"

[paul.smith]

Thanks jocamare.  It turns out the problem was caused by the return path being different as the traffic traversed the firewall through inside2 and returned through inside1 due to a route on the inside switch.  Ping (and other connectionless protocols) didn't care that they couldn't verify the traffic's origin (I think).

[jocamare]

If there was an Access-list allowing ICMP traffic on inside, it explains the reason why ping worked.