Question : CP Firewall – Delayed TCP reply – TCP packet out of state: First packet isn’t SYN; tcp_flags: FIN ACK
Some months ago I set up an Anti-spam/Anti-virus gateway on my network. I placed it in a DMZ. When originally set up checkpoint was at version NG FP3. My problem is the following;
As part of the AS/AV gateways spam detection I was trying to allow it communicate with two spamcop servers, vmx1 and vmx2.spamcop.net. The Reporting call goes out on TCP port 587. I also expect a reply over this connection.
I set up two security rules ;
1. my_gateway to any over any for tcp 587 accept log
when this rule failed to produce the goods I later added
2. vmx1 and vmx2.spamcop.net to my_gateway over any for any accept log
The call out to vmx1 or vmx2.spamcop.net:587 goes out, no problems. However, subsequent replies are dropped by the firewal, for example;
vmx2.spamcop.net (tcp 587) to my_gateway (origin outbound source port) dropped …
… reason ‘TCP port out of state: first packet isn’t SYN tcp_flags: FIN-ACK
OK, so I thought,
1. the call is going out
2. the reply is being sent
3. the firewall is stopping the reply
So then I thought that the session was timing out in the state table. I then went to the customised TCP service object for port 587 and changed it from the default timeout of 3600 seconds to 7200 seconds.
No change, packets still going out and replies still being stopped.
The firewall has been upgraded to NGX R65 in the meantime and still no change.
I believe there may be a delay in the reply by necessity, hence my efforts to extend the timeout. Is there any way I can exempt this specific type of call from the usual ‘State’ checks. I’m GUESSING SmartDefence is at the core of this.
Thankfully, the AS/AV gateway performs quite well despite this because it uses other checks, but I’d like to see if it improves with these calls working, and besides, it’s one of those nagging problems!
I’d love to know if anyone has come across this specific issue or indeed, something akin to it.
cheers
Solution: CP Firewall – Delayed TCP reply – TCP packet out of state: First packet isn’t SYN; tcp_flags: FIN ACK
Hi,
If you run the fw monitor with the “-p all” switch you will get one capture entry per step in the chain *per packet* – this will give you roughly 12-16 entries per packet in the capture log and this will account for the duplicates you can see, its actually just 1 or 2 packets.
I’ve just noticed that I omitted something in the wireshark setup:
Edit -> preferences -> columns -> New -> Title: FW Chain, Format: FW-1 monitor if/direction
This will give you another column in the capture and if you have set up the other settings as i explained in the first post then you should be able to see entries beside this e.g. i0,i1,i2 .. I6,I7,I8 … o1,o2 …O5,O6 etc etc.
This is the position of the packet in the chain as described by the output of fw ctl chain.
Here is an example of a firewall chain:
in chain (11):
0: -7f800000 (a0973cd8) IP Options Strip (ipopt_strip)
1: – 2000000 (a0e4cf80) vpn decrypt (vpn)
2: – 1fffff8 (a0e50d54) l2tp inbound (l2tp)
3: – 1fffff6 (a097488c) Stateless verifications (asm)
4: – 1fffff0 (a0e4ca90) vpn decrypt verify (vpn_ver)
5: – 1000000 (a098a66c) SecureXL conn sync (secxl_sync)
6: 0 (a093eae8) fw VM inbound (fw)
7: 2000000 (a0e4dfe0) vpn policy inbound (vpn_pol)
8: 10000000 (a098a800) SecureXL inbound (secxl)
9: 7f600000 (a096f950) fw SCV inbound (scv)
10: 7f800000 (a0973f24) IP Options Restore (ipopt_res)
out chain (9):
0: -7f800000 (a0973cd8) IP Options Strip (ipopt_strip)
1: – 1ffffff (a0e4c99c) vpn nat outbound (vpn_nat)
2: – 1f00000 (a097488c) Stateless verifications (asm)
3: 0 (a093eae8) fw VM outbound (fw)
4: 2000000 (a0e4db70) vpn policy outbound (vpn_pol)
5: 10000000 (a098a800) SecureXL outbound (secxl)
6: 1ffffff0 (a0e512fc) l2tp outbound (l2tp)
7: 20000000 (a0e4d494) vpn encrypt (vpn)
8: 7f800000 (a0973f24) IP Options Restore (ipopt_res)
On the packet capture in Wireshark:
i = pre-inbound
I = post-inbound
o = pre-outbound
O = post outbound
When the packet is with the little “ix”, this is it being checked by the kernel at stage x in the chain e.g. AV or vpn decrypt. Big Ix is after the kernel has inspected it then little “ox” is when it’s being inspected as it leaves the interface again and so on.
SO .. e.g. you can see the packets (port 587) coming in but only reaching e.g. i3 and then no more entries, you can look at your fw ctl chain output:
If for example stage 3 on the inbound chain is “stateless verifications” and stage 4 is “vpn decrypt verify” and your packet is getting no further than i3 then your packet is being dropped at stage 4, in this case “vpn decrypt verify” and you have a better idea of where to start looking.
As a side note, I also found this:
“The most common problem is asynchronous routing, meaning that the path that any given packet takes has multiple routes either inbound or outbound. It may also happen if SmartDefense drops a packet due to a SmartDefense violation, and removes the connection from the connection table. Once the connection has been removed from the connection table, any packet other than a syn will be dropped with a TCP packet out of state.”
