ASA5525-- Many Duplicate TCP SYN

[MicJameson1]

Hello.

Please see below (obfuscated) printout from security monitoring software...

Duplicate TCP SYN from Inside:10.2.1.99/47266 to Inside:10.2.200.46/445 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/15256 to Inside:10.2.200.43/80 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/33535 to Inside:10.2.200.49/135 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/47266 to Inside:10.2.200.55/445 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/13201 to Inside:10.2.200.56/443 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/13201 to Inside:10.2.200.53/443 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/13201 to Inside:10.2.200.40/443 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/34252 to Inside:10.2.200.39/25 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/35397 to Inside:10.2.200.54/23 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/13201 to Inside:10.2.200.37/443 with different initial sequence number
Duplicate TCP SYN from Inside:10.2.1.99/20 to Inside:10.2.200.37/139 with different initial sequence number
--

GIVEN:
-Above data refers to an ASA-5525 with OS Version 9.14(3)

-The source address is a datacenter server. The destination addresses are remote Anyconnect VPN users.
--

QUESTIONS:
What might be causing this symptom?

What is the next troubleshoot step?

Thank you.

[Rob Ingram]

@MicJameson1 so you created this static in order to redistribute this route for other devices in the network to communicate with the anyconnect pool? You've configured the ASA to something similar to one of the examples here

In which case change that static via the outside interface instead of the inside interface.

[MicJameson1]

(The existing config was input by someone else.)

In the linked text...

"Run the command show route static and we can easily determine the VPN static routes, the code is “V” identifies the /32 route learnt via the active VPN. Observe the keyword “advertised” for each VPN route, this indicates the route will automatically be advertised via a routing protocol.

Redistribution of the VPN routes can be achieved using a prefix-list to match the RAVPN IP network(s)"

These 2 statements seem contradictory. The first states the /32 routes "will be automatically advertised". The second states that "redistribuition can be achieved using a prefix-list".

So which is it?

In short, my goal is simply to fix the issue.

Questions:

1. Can you please clarify the confusion of the top 2 statements?

2. Can you please tell me the simplest way to fix this issue? (If I simply delete the static route, will the /32 endpoints automatically be advertised to the rest of the EIGRP network?)

Thank you.

[Rob Ingram]

@MicJameson1 that section in the guide is referring to redistributing a summary route of a /24 instead of 254 x /32, SSL-VPN will be automatically advertised and able to be redistributed unlike IPSec which needs RRI.

I am only guessing the use of this static route and not having seen your configuring I don't know if you have a prefix-list which matches that static route and therefore whether you rely on it or not. If you are relying on that route elsewhere in the network, then changing the route to outside instead of inside will resolve the initial issue whilst still redistributing that route.

[MicJameson1]

OK. Then it sounds like the safest way to proceed is to change the route from outside to inside...

from..."S  10.2.200.0 255.255.255.0 [1/0] via 10.2.222.3, Inside"

...to...

# route Outside 10.2.200.0 255.255.255.0 10.2.222.3

Is above correct?

Thank you.

[Rob Ingram]

@MicJameson1 does that mean its in use for redistribution purposes?

Yes that should be ok, you'd need to remove the other route via the inside interface first.

[MicJameson1]

There is no prefix list in the ASA config; thus My strategy will be simply to remove the static route...

"S  10.2.200.0 255.255.255.0 [1/0] via 10.2.222.3, Inside"...

And when this is done, my understanding is that the default configuration will then propagate the AnyConnect endpoint routes through EIGRP. as discussed in this link... ASA Reverse Route Injection (RRI) – integrating IT (wordpress.com)

Do you both agree that this is a sound plan?

[MHM Cisco World]

I see, you confuse because the link you share mention redistribute static 
the link clear this point  ""/32 static route""
so 

"S  10.2.200.0 255.255.255.0 [1/0] via 10.2.222.3, Inside". <<- delete this no need any static route for anyconnect 
and redistribute the static with prefix-list filter. 

“V” identifies the /32 route learnt via the active VPN

[Rob Ingram]

@MicJameson1 the only reason I can think you'd have a static route on the ASA representing the annconnect VPN pool, is if used as a summary route for redistribution. Without it you'd get hundreds of /32s routes redistributed if redistributing the connect VPN routes.

Although obviously your static is incorrect and causing excessive logs.

The /32 routes representing each connected anyconnect client are available to be redistributed, it doesn't mean they will be. That post also covers the subtle difference between SSL and IPsec connections, where IPsec requires RRI.

Have you actually checked the routing tables of the other devices? Do they have the /24 and the /32s? 

[MHM Cisco World · Accepted solution]

And all tcp packet you mention in your original post will be full your asa outside buffer.

Why I disagree this solution' the asa find longest match' the /32 is longest match and it represents active anyconnect and you can forward traffic to it

If not then asa use static route to host it not active.

This will full outside asa.

Delete it and use redistrubte connect.

It up to you 

This my view for this issue 

Thanks 

MHM

[MicJameson1]

We have 3 Anyconnect VPNs. I have confirmed that the other two Anyconnect VPNs do NOT use a static route as does the symptomatic Anyconnect VPN, and their /32 routes are propagating normally via EIGRP.

QUESTION: All i need to do is remove the problematic static route, and that's it?

Must I somehow configure already running EIGRP to distribute the dynamic /32 routes, or will that happen automatically?

Thank you.

[Rob Ingram]

@MicJameson1 well if you've confirmed the /24 static route is not received by the other network devices in the network, then remove it.

No, the /32 for SSL-VPN connections will be advertised only if redistributed in EIGRP. If using IPSec then you also need to configure RRI and redistribute.

FYI, if you are redistributing hundreds of /32 into the network, you will be flapping routes everytime someone logins and logoffs (when the routes are added and removed). Hence why I recommended advertising a summary route for the entire VPN ip pool range (per ASA), especially when you have 3 x ASA VPN's redistributing the routes.

[MicJameson1]

"well if you've confirmed the /24 static route is not received by the other network devices in the network, then remove it."-- There exist three Anyconnect VPNs in this enterprise.

In the two VPNs that do NOT have an Anyconnect /24 static route configured in the relevant ASA, the many /32 dynamic routes are seen as normal EIGRP routes on all devices in the network.

On the other hand, the Anyconnect subnet that DOES have the /24 static route, on all the network device routing tables is seen the many /32 static redistributed routes for that subnet.

on ALL the ASAs there exists NO prefix lists, or relevant access lists.

--

"FYI, if you are redistributing hundreds of /32 into the network, you will be flapping routes everytime someone logins and logoffs (when the routes are added and removed). Hence why I recommended advertising a summary route for the entire VPN ip pool range (per ASA), especially when you have 3 x ASA VPN's redistributing the routes."

I like this idea. May you please confirm the syntax of the summary static route?

But, wait a second, wont your idea cause the original issue? Must I then include prefix lists, access lists, route maps?

(I admit now this conversation is getting a bit confused with both you and MHMs input. I will also give his requested data, and you two can maybe come to a consensus on how the solution should be configured. but do please answer the above 2 questions now. Thank you.)

[Rob Ingram]

@MicJameson1 to be far, I did mention several posts ago that if you change that static route to "outside" instead of "inside" you won't get the original issue. The anyconnect pool logically exists on the outside interface.

The guide I previous provided covers this exact scenario, covering the static summary route, prefix, route map, you then redistribute into eigrp. You will then have a single /24 route in the network that won't flap.

[MHM Cisco World]

it static route /32 BUT it automatic add to RIB when the anyconenct active and remove when disconnected 
the link you previous share is excellent,

prefix-list RAVPN-ROUTES seq 5 permit VPN POOL/24 le 3
!
route-map VPN-ROUTES permit 10
 match ip address prefix-list RAVPN-ROUTES
!
router EIGRP xx
redistribute static subnets route-map VPN-ROUTES

[MicJameson1]

This enterprise has 3 Anyconnect VPNs.

You share a config with route map and prefix list. 

Other two Anyconnect VPNs in this enterprise have no route maps or prefix lists at all, and they work fine. Anyconnect routes in these other ASAs are being distributed simply with EIGRP.

Do you agree that all I need to do is remove the existing static route symptomatic ASA ?

In all these ASAs, does Anyconnect inject dynamic routes just because EIGRP is active, no additional config needed?