let ip option field "security" pass the gateway and do filtering on that field

[Ben_Hartmann]

Hi Community,

I am struggling with a unusual customer request. They are using the IP option "Security [130]" (RFC1108) in self-written software to tag special tcp-packets in the header. Now they want these packets to pass through the r80.20-gateway and implement filtering based on this IP option field.

Based on sk62082 (How to allow TCP/UDP packets with IP options through Check Point Security Gateway) it should be possible to let packets with these options passing the gateway.

Before implementing sk62082:
@;6765544;[SIM-206293920];handle_packet_do: stripping IP options failed, conn: <172.30.0.2,1024,10.125.231.130,10000,6>;

Changes based on sk62082 in $FWDIR/lib/table.def:

After implementing sk62082 (changed table.def & policy install):
@;6768953;[fw4_0];fw_log_drop_ex: Packet proto=6 172.30.0.2:1024 -> 10.125.231.130:10000 dropped by fw_ipopt_restore Reason: fw_ipopt_restore failed;

So even the simple forwarding of this security-field is failing on r80.20 (contrary to the sk). Any idea why the ipopt_restore is failing?

The packet looks like this:

And wireshark (on sending client) is successfully detection the IP option "Security":

For the 2nd part (the filtering) I am thinking about three possible options:

- 1.: special protocol type (maybe INSPECT code)
- 2.: custom application (based on sk103051)
- 3.: IPS signature

Has anyone of you worked with IP options on CheckPoint before? And is it even possible to filter based on a IP option field?

Based on the notes at the end of sk62082 (

"SecurePlatform OS / Gaia OS kernel does not strip IP options. Therefore, the packet arrives to Check Point kernel with IP options, and is dropped."

) I would think that the IP options are not stripped and therefor should be available for detection/filtering. But the following still shows a chain called "ipopt_strip":

Any help is kindly appreciated!

Kind regards,
Ben Hartmann
Security Consultant
Axians IT Security
Germany

[PhoneBoy]

When you say “implement filtering” what do you mean specifically?
Permit/deny packets based on the presence of this IP Option in the packet?
Note that by default we drop packets with IP Options set.
We can allow packets with specific IP Options set to be inspected as per the normal policy.

The fact we can’t restore IP Options to the packet suggests a bug that will need to be further investigation by the TAC.

[Ben_Hartmann]

Yes, I want to permit/deny based on the presence of this IP Option.

Regarding the restore of IP Option: I will open a ticket with TAC.

Kind regards,
Ben