topic Re: Lot of non-syn-tcp in General Topics

Lot of non-syn-tcp

paboy1 — Tue, 01 Dec 2020 17:23:18 GMT

Hi Experts,

we have a lot (I mean a LOT :-)) of non-syn-tcp traffic on our PA5220 cluster. The PA is in an enterprise company.

Are we sure that the non-syn-tcp means that there is an asymmetric flow? Let me give you an example:

1) Host A sends a SYN to Host B passing through PA

2) PA recognize it properly and establish a sessione in its session table

3) Host B receive that SYN and start the standard comunication.

Host A has its timeout idle session at 3 hours;

Host B has its timeout idle session at 3 hours;

Palo Alto has ita timeoute idle TCP session at 1 hour.

After 1.5 hour the host A send a TCP Keep-Alive but on the PA the the session doesn't exist anymore... the timeout was expired.

So, that flow will be recognized as non-syn-tcp. But it is not an Asymmetric Flow.

Anyway, do you know if there is some other situation where the non-syn-tcp not mean Asymmetric Routing?

Bye!

Re: Lot of non-syn-tcp

S.Cantwell — Tue, 01 Dec 2020 22:43:37 GMT

Hello there!

I think you explained the only 2 examples that I could think of.

But I also do not think any keep-alive after the 3600 sec would keep a flow open, when the session itself is closed, the application/connection would drop.

So are you saying that things are working fine, and you see a bunch of keep alives, or are you saying that the connection is dropped at the 1.5 hour mark, because there is no more session for the FW to inspect?

Thanks

Re: Lot of non-syn-tcp

reaper — Tue, 01 Dec 2020 23:51:07 GMT

Well non-syn-tcp means the firewall is receiving 'first' packets (ones that don't belong to an existing flow) that are not SYN, so there has not been a proper TCP handshake

this does not mean traffic is asymmetrical, asymmetric routing is just one of the more common causes that the firewall is receiving ACK packets where no session exists

In your further example this is highlighted: session is torn down before either side is actually done talking, causing the firewall to receive an ACK packet for a non-existent session

This can be solved by editing the application and increasing the lifetime and idle timers to correspond with the expected time between keepalives