topic Firewall State Table in General Topics

Firewall State Table

James_Simmons — Tue, 15 Jan 2019 19:55:10 GMT

I have a situation where I need affirmation on my thoughts. Here goes.

Setup:

Firewall Cluster - R77.30 - Open Server

Management Interface

External Interface

Internal Interface

Core Interface

Set up as a basic Firewall no other blade enabled.

Static Routes setup for Management Services....i.e NTP, AD, SMTP, Syslog via Management Interface.

Situation: Traffic Originates from Internal interface and follows routes out Management Interface; however, when return traffic is observed via fwmonitor we see the Return traffic traverse the Core interface and then to Internal Interface where the originating server lives.

[vs_0][fw_3] Internal:i[52]: 192.168.231.93 -> 10.128.232.101 (TCP) len=52 id=21750
TCP: 62298 -> 49155 .S.... seq=c55bc946 ack=00000000
[vs_0][fw_3] Internal:I[52]: 192.168.231.93 -> 10.128.232.101 (TCP) len=52 id=21750
TCP: 62298 -> 49155 .S.... seq=c55bc946 ack=00000000
[vs_0][fw_3] Managment:o[52]: 192.168.231.93 -> 10.128.232.101 (TCP) len=52 id=21750
TCP: 62298 -> 49155 .S.... seq=c55bc946 ack=00000000
[vs_0][fw_3] Managment:O[52]: 192.168.231.93 -> 10.128.232.101 (TCP) len=52 id=21750
TCP: 62298 -> 49155 .S.... seq=c55bc946 ack=00000000
[vs_0][fw_3] Core:i[52]: 10.128.232.101 -> 192.168.231.93 (TCP) len=52 id=3954
TCP: 49155 -> 62298 .S..A. seq=6e88bb0b ack=c55bc947
[vs_0][fw_3] Core:I[52]: 10.128.232.101 -> 192.168.231.93 (TCP) len=52 id=3954
TCP: 49155 -> 62298 .S..A. seq=6e88bb0b ack=c55bc947
[vs_0][fw_3] Internal:o[52]: 10.128.232.101 -> 192.168.231.93 (TCP) len=52 id=3954
TCP: 49155 -> 62298 .S..A. seq=6e88bb0b ack=c55bc947
[vs_0][fw_3] Internal:O[52]: 10.128.232.101 -> 192.168.231.93 (TCP) len=52 id=3954

Question: Is normal Check Point State Synchronization? As long as the firewall has a SYN packet for the connection in the state table it doesn't matter if the SYNACK packet comes over a different interface. Is my thinking correct? Some people would say there should be an Out-of-State error, but my understanding that is only if the firewall receives a packet that doesn't not have a state/connection entry.

Re: Firewall State Table

PhoneBoy — Tue, 15 Jan 2019 21:40:05 GMT

What you describe should not impact the state table.

Where you might have an issue is with anti-spoofing, which might drop the reply traffic because it's coming on the wrong interface.

Re: Firewall State Table

James_Simmons — Tue, 15 Jan 2019 21:43:24 GMT

So far no issues with that because on the Management interface we have the more specific hosts in the AS and on the Core Interface the AS is all RFC1918 which it will match as well.

Re: Firewall State Table

Hybrid_Theory — Tue, 15 Jan 2019 21:54:07 GMT

It does matter, unless you have unticked the Drop out of state packets in the Global properties...

I would have thought that return packet be dropped though. Have you added that host into your Anti Spoofing group for the Core interface?

Re: Firewall State Table

Timothy_Hall — Wed, 16 Jan 2019 13:13:38 GMT

As long as both the forward c2s flow and return flow of s2c packets associated with a connection traverse the firewall (even asymmetrically through different firewall interfaces), they will not be dropped as TCP out of state. As Dameon mentioned, this can however run afoul of antispoofing depending on how the interface topologies are defined.

Now if one of those connection's flows traverses the firewall but the other one does not due to asymmetry in the surrounding network config, that is a different story and yes the connection will be dropped if "Drop out of state TCP" is set.

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30