ATTENTION: We are currently working an issue with posting. Thank you for your patience while we work on a resolution.
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
917
Views
0
Helpful
7
Replies

ASA problem with routing

schwarz-michael
Level 1
Level 1

Hello I have a big problem with ASA routing,

I have two locations with a ASA5515 Cluster Vers 8.2 at one side and a ASA 5525 Cluster Vers 9.2 at the other side. Both sides are connected with a server DMZ zone. At the server I have entered a static route to one of the firewall systems. The communication seem to be well but after a while 10 minutes or later the communication breaks. The wireshark analyzer shows that at point of break the packet to the server system came with the source mac address of the firewall system from the other side.  I don´t know how I can fix the problem. 

Have anybody an idea to solve the problem.

Best regards,

Michael

7 Replies 7

Murali
Level 1
Level 1

Hi Michael,

How the two ASA clusters are connected to each other ? what type of connection , how the routing works between them?

Also if you can give us packet capture output we can understand the issue better.Thanks!

Murali

Hello Murali,

both firewall cluster are connected by a redundant gbit leased line.

My problem is that the vpn router had a static route over FW cluster site-A, at the error situation after ten minutes or some hours I can see traffic from client at vpn site  through the FW cluster at site-B and the connection breaks. After a while the traffic comes over FW Cluster site-A and the Connection is all right.

At the document you can see the Topologie and the logs of the FW Cluster and capture of the Server traffic

 

Best regards.

Michael 

Hello Michael,

Looks like this is asynchronous routing , the reverse path is not the same as the original path.

I can see HSRP is configured on the routers so checking routing for your server subnets 10.17.1.x on the routers might help you. What path (traceroute) HSRP router is  taking to reach 10.17.1.x subnet is important.

HTH.

Murali.

Hello Murali,

thank you for your Information.

Yes of course that seem to be a problem of asynchronous routing. First I have entered the explizit and supernet routes at the hsrp routers with different metrics, second I have disabled HSRP at the standby node so that only one routing instance is there. The problem is still available. I don't know what instance send the return packets through the firewall with ip 10.200.0.224 . At the netxt step I entered at the 10.200.0.224 firewall at the outside Interface routes for Destination 10.17.1.117 over Gateway 10.200.0.222, after that the communication works without breaks but I also can see a lot of wrong packets at both sites.

Thanks

Michael    

Hey Michael,

Good to hear you made some progress on this one , so from this what i understood is there is routing issue on the HSRP routers (it could be having two routes for the 10.17.1.x subnet ; one to .222  ASA , and second to .224 ASA) when you entered route on the .224 ASA pointing back to .222 your connection is working.

so routers could be sending some packets to .224 ASA. With the limited information of how your routing is configured this is what i understood.

 

HTH

Murali.


 

Hello Murali,

we have solved the problem of async. routing, I will inform you:

 

Problem

Packets specially defined for server at site-A was sporadically delivered by gateway of Site-B regardless of static routing so the server connection at Site-A breaks.

Reason

- at site-B the Firewall is connected to a Switch, the  CAM table of the switch aged out MAC address of GW.222 from site-A

- so switch flooded packet for GW.222 to all switch-ports also to the FW.224

- firewall GW.224 get the packet with MAC destination of GW.222,

because FW.224 have a direct connected interface 10.17.0.0 the packet to 10.17.x.x. server was directly delivered by firewall.224

Solution

- traffic for GW.222 specially deny at firewall.224

- traffic for GW.224 specially deny at firewall.222

- define static MAC address of GW.222 at CAM table of switch

 

Best regards

Michael

Ah switch was the culprit then :) great you figured it out and solved your issue.

Murali.

Review Cisco Networking for a $25 gift card