ASA static routes

[xayavongp]

From the ASA (v 9.1) I have static routes to /30 that sits behind the VPN routers.

on ASA:

route outside x.x.x.124 255.255.255.252  x.x.x.1 1

route outside x.x.x.128 255.255.255.252  x.x.x.2 1

.

.

.

route outside x.x.x.148 255.255.255.252 x.x.x.7 1

I see in the routing table that there is an addtional static route that is learn that seems to summarize all the /30 (even though the /30 are not in the range). Why is that ? I was starting to believe this might be causing some of the duplicate tcp syn issues I'm seeing.

ASA# show route outside

S x.x.x.0 255.255.255.0 [1/0] via x.x.x.1, outside

S x.x.x.124 255.255.255.252 [1/0] via x.x.x.1, outside

.

.

.

route outside x.x.x.148 255.255.255.252 [1/0] via x.x.x.7, outside

[Jouni Forss]

Hi,

Unless you actually have a configured "route" command for the network with the /24 mask then I would have to guess that some VPN configuration on this device is adding the route dynamically based on the VPN configurations.

For example if you have a L2L VPN configurations and have the following line in the configuration

crypto map

Then this configuration will add a route for the destination network in the ACL configured in the command

crypto map

So that would probably be something I would check.

- Jouni

[xayavongp]

Yes this is a L2L configuration. Removing the "reverse-route" did remove the /24 static. Thought that would fix it but no.

Testing with only two peers right now. It seems whichever peer is able to establish the IPsec SA first can pass traffic.

The other one can establish IPSEC SA but can't pass traffic. It spits out error ASA-4-419002 (Dup TCP SYN).

Any thoughts?

-Pete

[Jouni Forss · Accepted solution]

Hi,

What exactly are you trying to do?

What is the purpose of the /30 routes?

If you have 2 L2L VPN connections configured with some overlapping network in the Crypto ACL than the "crypto map" configuration with the lower value of the above section will be matched when the VPN negoations start and to my understanding the second connection in order will never be matched.

But again, I am not sure what you are attempting to do.

With regards to the duplicate SYN I am not 100% sure but it might indicate a situation where a TCP SYN has been seen and also the TCP SYN ACK but again a TCP SYN is seen from the initial host since it has not received the TCP SYN ACK that the ASA has seen.

- Jouni

[xayavongp]

supportforums-beta.cisco.com

[xayavongp]

It appears that the first router creates a proxy session for for the same subnet the second router should be answering for. I assume the ASA drops the packet and is seen as an attack.  I did disable proxyarp on inside and outside. I'm wondering if the same broadcast domain is causing this issue.

[xayavongp]

You are correct..Should have carefully read your response. The ACLs are a match first session and the second one never processes it. We were trying to cover the remote networks with one line ( like a /24). So now we will have to create individual ACLs per each remote network per peer and not overlap.

I was hoping the ASA would be more flexible in how it processes the ACLs so we could only work with one ACL line.