syn-ack on every IP address on port tcp_80 during vulnerability scan

[gnovokmet]

Dear Community,

I would like to share with you strange behavior and maybe someone will have a clue and point me where to look further. During our vulnerability scan in network, I have noticed vulnerability map scan detects that port tcp 80 is opened and IP host is alive on every IP address that doesn't exist in the network. I have simulated MAP scan with NMAP and result is the same: I get syn-ack packet from Checkpoint Gateway on every IP address that doesn't exist. (capture1.png)

Telnet to IP address shows it is connected (capture2.png)

FW monitor - capture3.png

While investigating this, I noticed that all this started  when Autonomous Threat Prevention was enabled on the Security Gateway (capture4.png). When it is changed to custom, I don't have this issue. MAP scan detects that we have 3k live hosts even the real number is 30 and I would like to solve this issue while keeping the Autonomous Threat Prevention on Gateway on.

Security Gateway: R81.10, JHA take 78

Any suggestion is more then welcomed! Many thanks.

[PhoneBoy]

What ATP profile are you using?
Do you see any logs when this occurs?
If you haven't already done so, I recommend opening a TAC case: https://help.checkpoint.com 

[gnovokmet]

Autonomous profile: perimeter

In the logs, I see that packet is dropped on gateway.

[HeikoAnkenbrand]

I think the Accelerated SYN Defender is turned on on your gateway.

A TCP SYN Flood attack occurs when a host, typically with a forged IP address, sends a flood of TCP [SYN] packets. Each of these TCP [SYN] packets is handled as a connection request, which causes the server to create a half-open (unestablished) TCP connection. This occurs because the server sends a TCP [SYN+ACK] packet, and waits for a response TCP packet that does not arrive.

These half-open TCP connections eventually exceed the maximum available TCP connections. This causes a denial of service condition.

The Check Point Accelerated SYN Defender protects the Security GatewayClosed by preventing excessive TCP connections from being created.

The Accelerated SYN Defender uses TCP [SYN] Cookies (particular choices of initial TCP sequence numbers) when under a suspected TCP SYN Flood attack. Using TCP [SYN] Cookies can reduce the load on Security Gateway and on computers behind the Security Gateway. The Accelerated SYN Defender acts as proxy for TCP connections and adjusts TCP {SEQ} and TCP {ACK} values in TCP packets.

1. A Client sends a TCP [SYN] packet to a Server.

2. The Accelerated SYN Defender replies to the Client with a TCP [SYN+ACK] packet that contains a special cookie in the Seq field.

   Security Gateway does not maintain the connection state at this time.

3. The Client sends a reply TCP [ACK] packet. This completes the Client-side of the TCP connection.

4. The Accelerated SYN Defender checks if the SYN cookie in the Client's TCP [ACK] packet is legitimate.

5. If the SYN cookie in the Client's TCP [ACK] packet is legitimate, the Accelerated SYN Defender sends a TCP [SYN] packet to the Server to begin the Server-side of the TCP connection.

6. The Server replies with a TCP [SYN+ACK] packet.

7. The Accelerated SYN Defender sends a TCP [ACK] packet to complete the Server-size of the TCP 3-way handshake.

8. The Accelerated SYN Defender marks the TCP connection as established and records the TCP sequence adjustment between the two sides.

[gnovokmet]

That is the first thing I have checked. When disabled, same behavior. Please see capture5.png attachment.

[HeikoAnkenbrand]

I do not see SYN-ACK in the "fw monitor" image (capture3.png) from your gateway.


You see here only a SYN and a RST packet from the nmap scanner.
If the fw monitor filter is set correctly, this is probably an nmap problem.

But maybe the fw monitor filter is not set correctly

[gnovokmet]

You are right, it is only a SYN and a RST packet. output is from FW monitor on the gateway. However, telnet shows connected, nmap shows that port is open.

No protocol signature is enabled on http.

[Bob_Zimmerman]

What is the exact filter you used when capturing that fw monitor?

Lots of client-side URL filtering systems spoof responses from all IPs on various ports. I know the Zscaler agent does, and it's incredibly irritating. This behavior breaks the ability to test whether a service is actually listening, and the ability to see what certificate the service actually presents if it is listening.

[gnovokmet]

fw monitor -e "host(10.28.129.1) and host(10.30.100.222), accept;"
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_off
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of fwmonitorfreebufs
************************************************************** NOTE **************************************************************
*** Using "-e" filter will not monitor accelerated traffic. To monitor and filter accelerated traffic please use the "-F" filter ***
************************************************************************************************************************************
FW monitor will record only ip & transport layers in a packet
For capturing the whole packet please do -w
PPAK 0: Get before set operation succeeded of fwmonitor_ppak_all_position
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
PPAK 0: Get before set operation succeeded of fwmonitormaxpacket
PPAK 0: Get before set operation succeeded of fwmonitormask
PPAK 0: Get before set operation succeeded of fwmonitorallocbufs
PPAK 0: Get before set operation succeeded of printuuid
[vs_0][fw_1] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=45811
TCP: 33088 -> 443 .S.... seq=e2a5eb9c ack=00000000
[vs_0][fw_2] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=4176
TCP: 49802 -> 80 .S.... seq=f8affa70 ack=00000000
[vs_0][fw_2] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=62011
TCP: 49802 -> 80 ..R... seq=f8affa70 ack=00000000
[vs_0][fw_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=27271
TCP: 49806 -> 80 .S.... seq=d78d3081 ack=00000000
[vs_0][fw_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=58255
TCP: 49806 -> 80 ..R... seq=d78d3081 ack=00000000

[Bob_Zimmerman]

What do you get if you try with the -F filter syntax like the warning at the top recommends?

fw monitor -F "10.28.129.1,0,10.30.100.222,0,0" -F "10.30.100.222,0,10.28.129.1,0,0"

[gnovokmet]

nmap command: nmap -vv 10.30.100.222 -p 80

This is the output of fw monitor with -F:

[vs_0][ppak_0] eth1:iqD[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=18854
TCP: 35258 -> 443 .S.... seq=9740b2ee ack=00000000
[vs_0][ppak_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=18854
TCP: 35258 -> 443 .S.... seq=9740b2ee ack=00000000
[vs_0][fw_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=18854
TCP: 35258 -> 443 .S.... seq=9740b2ee ack=00000000
[vs_0][ppak_0] eth1:iqD[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=42732
TCP: 51972 -> 80 .S.... seq=2528f946 ack=00000000
[vs_0][ppak_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=42732
TCP: 51972 -> 80 .S.... seq=2528f946 ack=00000000
[vs_0][ppak_0] eth1:iqD[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=26687
TCP: 51972 -> 80 ..R... seq=2528f946 ack=00000000
[vs_0][ppak_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=26687
TCP: 51972 -> 80 ..R... seq=2528f946 ack=00000000
[vs_0][fw_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=42732
TCP: 51972 -> 80 .S.... seq=2528f946 ack=00000000
[vs_0][fw_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=26687
TCP: 51972 -> 80 ..R... seq=2528f946 ack=00000000
[vs_0][ppak_0] eth1:iqD[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=21286
TCP: 51976 -> 80 .S.... seq=3d728a22 ack=00000000
[vs_0][ppak_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=21286
TCP: 51976 -> 80 .S.... seq=3d728a22 ack=00000000
[vs_0][ppak_0] eth1:iqD[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=1274
TCP: 51976 -> 80 ..R... seq=3d728a22 ack=00000000
[vs_0][ppak_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=1274
TCP: 51976 -> 80 ..R... seq=3d728a22 ack=00000000
[vs_0][fw_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=21286
TCP: 51976 -> 80 .S.... seq=3d728a22 ack=00000000
[vs_0][fw_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=1274
TCP: 51976 -> 80 ..R... seq=3d728a22 ack=00000000

[Bob_Zimmerman]

To be sure, you used the -F for both directions, like I wrote?

That capture doesn't show any traffic coming from the firewall. If you had -F filters for both directions and you're getting a successful connection on the client, then something else between them is spoofing the reply.

[gnovokmet]

I've lost you know... How do you mean in both directions?

NMAP (10.28.129.1) is behind FW1 and 10.30.100.0/24 is terminated behind FW2, where 10.30.100.222 IP address doesn't exist.

Here are the outputs of FW monitor from both FW...

FW1:

[Expert@FW1:0]# fw monitor -F "10.28.129.1,0,10.30.100.222,0,0" -F "10.30.100.222,0,10.28.129.1,0,0"
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_off
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of fwmonitorfreebufs
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
fw ctl set string simple_debug_filter_saddr_1 10.28.129.1 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_saddr_1
fw ctl set int simple_debug_filter_sport_1 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_sport_1
fw ctl set string simple_debug_filter_daddr_1 10.30.100.222 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_daddr_1
fw ctl set int simple_debug_filter_dport_1 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_dport_1
fw ctl set int simple_debug_filter_proto_1 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_proto_1
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
fw ctl set string simple_debug_filter_saddr_2 10.30.100.222 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_saddr_2
fw ctl set int simple_debug_filter_sport_2 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_sport_2
fw ctl set string simple_debug_filter_daddr_2 10.28.129.1 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_daddr_2
fw ctl set int simple_debug_filter_dport_2 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_dport_2
fw ctl set int simple_debug_filter_proto_2 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_proto_2
FW monitor will record only ip & transport layers in a packet
For capturing the whole packet please do -w
PPAK 0: Get before set operation succeeded of fwmonitor_ppak_all_position
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
PPAK 0: Get before set operation succeeded of fwmonitormaxpacket
PPAK 0: Get before set operation succeeded of fwmonitormask
PPAK 0: Get before set operation succeeded of fwmonitorallocbufs
PPAK 0: Get before set operation succeeded of printuuid
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=2054
TCP: 52156 -> 80 .S.... seq=96e77572 ack=00000000
[vs_0][fw_2] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=2054
TCP: 52156 -> 80 .S.... seq=96e77572 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][fw_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=2054
TCP: 52156 -> 80 .S.... seq=96e77572 ack=00000000
[vs_0][fw_2] bond0:Iq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=19528
TCP: 80 -> 52156 .S..A. seq=03e58329 ack=96e77573
[vs_0][fw_2] bond1.129:oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=19528
TCP: 80 -> 52156 .S..A. seq=03e58329 ack=96e77573
[vs_0][fw_2] bond1.129:Oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=19528
TCP: 80 -> 52156 .S..A. seq=03e58329 ack=96e77573
[vs_0][fw_0] bond1.129:Iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][fw_0] bond0:oq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][ppak_0] bond0:Oqe[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=52 id=2055
TCP: 52156 -> 80 ....A. seq=96e77573 ack=03e5832a
[vs_0][fw_2] bond1.129:Iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=336
TCP: 52156 -> 80 .S.... seq=97277572 ack=00000000
[vs_0][fw_2] bond0:oq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=336
TCP: 52156 -> 80 .S.... seq=97277572 ack=00000000
[vs_0][ppak_0] bond0:Oqe[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=336
TCP: 52156 -> 80 .S.... seq=97277572 ack=00000000
[vs_0][fw_2] bond0:Iq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=52 id=50459
TCP: 80 -> 52156 ....A. seq=03e5832a ack=96e77573
[vs_0][fw_2] bond1.129:oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=52 id=50459
TCP: 80 -> 52156 ....A. seq=03e5832a ack=96e77573
[vs_0][fw_2] bond1.129:Oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=52 id=50459
TCP: 80 -> 52156 ....A. seq=03e5832a ack=96e77573
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=52 id=2056
TCP: 52156 -> 80 ..R.A. seq=96e77573 ack=03e5832a
[vs_0][fw_2] bond1.129:Iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=15536
TCP: 52156 -> 80 ..R... seq=97277572 ack=00000000
[vs_0][fw_2] bond0:oq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=15536
TCP: 52156 -> 80 ..R... seq=97277572 ack=00000000
[vs_0][ppak_0] bond0:Oqe[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=15536
TCP: 52156 -> 80 ..R... seq=97277572 ack=00000000
[vs_0][ppak_0] bond1.129:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=0
TCP: 52156 -> 80 ..R... seq=96e77573 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=46372
TCP: 52160 -> 80 .S.... seq=33b5c784 ack=00000000
[vs_0][fw_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=46372
TCP: 52160 -> 80 .S.... seq=33b5c784 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=46372
TCP: 52160 -> 80 .S.... seq=33b5c784 ack=00000000
[vs_0][fw_0] bond0:Iq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=16362
TCP: 80 -> 52160 .S..A. seq=825ff256 ack=33b5c785
[vs_0][fw_0] bond1.129:oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=16362
TCP: 80 -> 52160 .S..A. seq=825ff256 ack=33b5c785
[vs_0][fw_0] bond1.129:Oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=16362
TCP: 80 -> 52160 .S..A. seq=825ff256 ack=33b5c785
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=52 id=46373
TCP: 52160 -> 80 ....A. seq=33b5c785 ack=825ff257
[vs_0][fw_0] bond1.129:Iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=29627
TCP: 52160 -> 80 .S.... seq=33f5c784 ack=00000000
[vs_0][fw_0] bond0:oq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=29627
TCP: 52160 -> 80 .S.... seq=33f5c784 ack=00000000
[vs_0][fw_0] bond0:Iq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=52 id=46155
TCP: 80 -> 52160 ....A. seq=825ff257 ack=33b5c785
[vs_0][fw_0] bond1.129:oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=52 id=46155
TCP: 80 -> 52160 ....A. seq=825ff257 ack=33b5c785
[vs_0][fw_0] bond1.129:Oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=52 id=46155
TCP: 80 -> 52160 ....A. seq=825ff257 ack=33b5c785
[vs_0][ppak_0] bond0:Oqe[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=29627
TCP: 52160 -> 80 .S.... seq=33f5c784 ack=00000000
[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=52 id=46374
TCP: 52160 -> 80 ..R.A. seq=33b5c785 ack=825ff257
[vs_0][fw_0] bond1.129:Iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=10443
TCP: 52160 -> 80 ..R... seq=33f5c784 ack=00000000
[vs_0][fw_0] bond0:oq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=10443
TCP: 52160 -> 80 ..R... seq=33f5c784 ack=00000000
[vs_0][ppak_0] bond0:Oqe[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=10443
TCP: 52160 -> 80 ..R... seq=33f5c784 ack=00000000
[vs_0][ppak_0] bond1.129:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=0
TCP: 52160 -> 80 ..R... seq=33b5c785 ack=00000000
^C monitor: caught sig 2

FW2:

[Expert@FW2:0]# fw monitor -F "10.28.129.1,0,10.30.100.222,0,0" -F "10.30.100.222,0,10.28.129.1,0,0"
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_off
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of fwmonitorfreebufs
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
fw ctl set string simple_debug_filter_saddr_1 10.28.129.1 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_saddr_1
fw ctl set int simple_debug_filter_sport_1 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_sport_1
fw ctl set string simple_debug_filter_daddr_1 10.30.100.222 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_daddr_1
fw ctl set int simple_debug_filter_dport_1 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_dport_1
fw ctl set int simple_debug_filter_proto_1 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_proto_1
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
fw ctl set string simple_debug_filter_saddr_2 10.30.100.222 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_saddr_2
fw ctl set int simple_debug_filter_sport_2 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_sport_2
fw ctl set string simple_debug_filter_daddr_2 10.28.129.1 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_daddr_2
fw ctl set int simple_debug_filter_dport_2 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_dport_2
fw ctl set int simple_debug_filter_proto_2 0 -a
PPAK 0: Get before set operation succeeded of simple_debug_filter_proto_2
FW monitor will record only ip & transport layers in a packet
For capturing the whole packet please do -w
PPAK 0: Get before set operation succeeded of fwmonitor_ppak_all_position
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
PPAK 0: Get before set operation succeeded of fwmonitormaxpacket
PPAK 0: Get before set operation succeeded of fwmonitormask
PPAK 0: Get before set operation succeeded of fwmonitorallocbufs
PPAK 0: Get before set operation succeeded of printuuid
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
[vs_0][ppak_0] eth1:iqD[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][ppak_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][fw_2] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=43334
TCP: 35442 -> 443 .S.... seq=236e6d08 ack=00000000
[vs_0][ppak_0] eth1:iqD[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=336
TCP: 52156 -> 80 .S.... seq=97277572 ack=00000000
[vs_0][ppak_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=336
TCP: 52156 -> 80 .S.... seq=97277572 ack=00000000
[vs_0][ppak_0] eth1:iqD[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=15536
TCP: 52156 -> 80 ..R... seq=97277572 ack=00000000
[vs_0][ppak_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=15536
TCP: 52156 -> 80 ..R... seq=97277572 ack=00000000
[vs_0][fw_2] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=336
TCP: 52156 -> 80 .S.... seq=97277572 ack=00000000
[vs_0][fw_2] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=15536
TCP: 52156 -> 80 ..R... seq=97277572 ack=00000000
[vs_0][ppak_0] eth1:iqD[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=29627
TCP: 52160 -> 80 .S.... seq=33f5c784 ack=00000000
[vs_0][ppak_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=29627
TCP: 52160 -> 80 .S.... seq=33f5c784 ack=00000000
[vs_0][ppak_0] eth1:iqD[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=10443
TCP: 52160 -> 80 ..R... seq=33f5c784 ack=00000000
[vs_0][ppak_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=10443
TCP: 52160 -> 80 ..R... seq=33f5c784 ack=00000000
[vs_0][fw_0] eth1:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=64 id=29627
TCP: 52160 -> 80 .S.... seq=33f5c784 ack=00000000
[vs_0][fw_0] eth1:iq[40]: 10.28.129.1 -> 10.30.100.222 (TCP) len=40 id=10443
TCP: 52160 -> 80 ..R... seq=33f5c784 ack=00000000
^C monitor: caught sig 2
monitor: unloading

[Bob_Zimmerman]

The -F filters only look for exact source IP, source port, destination IP, destination port, and protocol. If you only use -F a single time, you will only capture one direction of a connection. You would see the SYN, but not the SYN-ACK. Since your capture only showed the SYN and the RST from the client to the server, I was asking if you included -F filters for both directions like in the command I wrote. Seems you did.

The fw monitor output you've provided suggests 10.28.129.1 or 10.30.100.222 (or possibly both) is used in some NAT rule. The destination is translated between little-i and big-I by default. We never see a big-I for the SYN.

The SYN-ACK comes back in FW1 bond0. What is out that interface?

[gnovokmet]

FW1 bond0 is ISP interface, bond is created to ISP SW for redundancy.

[Timothy_Hall]

You need to use -F with fw monitor as Bob mentioned.  When using fw monitor -e you are only capturing the first packet of the connection and nothing else.  This is because the first packet of every new connection goes F2F to get a rulebase lookup, and if it is then offloaded back into the Medium or Fast paths fw monitor -e can't see any of the connection's packets anymore.  fw monitor -F will show you all matching packets regardless of path, because the -F capture is happening in the SecureXL/sim driver itself.

[Wolfgang]

The Zscaler mentioned by @Bob_Zimmerman  is a good hint. All your packet captures shows only one direction, from nmap host to the gateway. No returning packet seen which is needed to get a connect to port 80. Did you tried the same from another source host. Maybe something on the source intercepts the traffic?

[gnovokmet]

It is happening only on port 80, all other ports are filtered.

[HeikoAnkenbrand]

Hi @gnovokmet,

[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=46372
TCP: 52160 -> 80 .S.... seq=33b5c784 ack=00000000

>>> Packet arrives at the Performance Pack - OK

[vs_0][fw_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=46372
TCP: 52160 -> 80 .S.... seq=33b5c784 ack=00000000

>>> Packet is forwarded to the CoreXL instance via dynamic dispatcher - OK

[vs_0][ppak_0] bond1.129:iq[44]: 10.28.129.1 -> 10.30.100.222 (TCP) len=60 id=46372
TCP: 52160 -> 80 .S.... seq=33b5c784 ack=00000000

>>> Now the packet is probably reinjected.
>>> Is new since R80.20 (more read here 
       (Update R80.20+ Security Gateway Architecture (Logical Packet Flow)).

>>> But could also be a second "SYN" package.

>>> Interesting is that there is no "I" package.
>>> Could be due to the "NAT" that the filter no longer takes effect.

[vs_0][fw_0] bond0:Iq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=16362
TCP: 80 -> 52160 .S..A. seq=825ff256 ack=33b5c785

>>> Now comes a response package without a small "i".
>>> This indicates to me that a "NAT" is taking place here.

[vs_0][fw_0] bond1.129:oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=16362
TCP: 80 -> 52160 .S..A. seq=825ff256 ack=33b5c785

[vs_0][fw_0] bond1.129:Oq[44]: 10.30.100.222 -> 10.28.129.1 (TCP) len=64 id=16362
TCP: 80 -> 52160 .S..A. seq=825ff256 ack=33b5c785

>>> Now the packet SYN/ACK is delivered on the outgoing interface by lowercase "o" and uppercase "O" inspection point.

-------------------------------------------

It looks like to me, that the scanned addresses are send per NAT to an internal system that actually responds.

Please check your NAT rules!

Could also possibly be the following problem:
- Global Properties option that allows admins to choose between "Client side NAT" and "Server side NAT"
- IP pool NAT

[gnovokmet]

Hi,

thank you for your time and analyzing this. There is a rule in policy that keeps original source/destination network, meaning "no nat" between these two networks.

I think we went away from the initial findings and that is: all this is happening with enabling Autonomous Threat Prevention IPS policy on the FW1 gateway. When I change it to custom IPS policy, packet to any IP address on port 80 is filtered, according to FW rules. Q: is there any way I can exclude this or somehow do a debug to find out which IPS policy is matched to prove my point? 

[PhoneBoy]

Have you opened a TAC case on this?
It's highly recommended here: https://help.checkpoint.com

[Timothy_Hall]

Check the service http and any other ones that may have been created to match TCP port 80, do you have Protocol Signature set for any of them?