cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question
RickHoppe
Silver

id, ID and OE inspection points in R80.20 GA?

Hi all,

I'm playing with R80.20 GA in my LAB (which is in fact running on my laptop using VirtualBox) and I'm setting up a IPSec VPN between 2 Security Gateways.

When I'm watching the traffic with fw monitor I do not see the inspection points we were used to since R80.10 (see  fw monitor inspection point e or E for more information).

My LAB looks like this:

Local gateway: 192.168.202.80

Peer: 192.168.202.90

Local VPN Domain: 192.168.3.0/24

Remote VPN Domain: 192.168.2.0/24

I'm initiating SSH traffic from 192.168.3.100 to 192.168.2.2 which does enter the IPSec VPN. The SSH connection does work fine.

However, I see these "inspection points" with fw monitor: id, ID, o , O and OE on the local gateway where the SSH client resides in a directly connected network (eth2).

FYI, SecureXL was still enabled when fw monitor was started.

[Expert@GW2:0]# fw monitor -e 'accept (host(192.168.3.100) and host(192.168.2.2)) or esp;'
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_0] eth2:id[52]: 192.168.3.100 -> 192.168.2.2 (TCP) len=52 id=24338
TCP: 50393 -> 22 .S.... seq=71548dfe ack=00000000
[vs_0][fw_0] eth2:ID[52]: 192.168.3.100 -> 192.168.2.2 (TCP) len=52 id=24338
TCP: 50393 -> 22 .S.... seq=71548dfe ack=00000000
[vs_0][fw_0] eth1:o[52]: 192.168.3.100 -> 192.168.2.2 (TCP) len=52 id=24338
TCP: 50393 -> 22 .S.... seq=71548dfe ack=00000000
[vs_0][fw_0] eth1:O[52]: 192.168.3.100 -> 192.168.2.2 (TCP) len=52 id=24338
TCP: 50393 -> 22 .S.... seq=71548dfe ack=00000000
[vs_0][fw_1] eth1:O[52]: 192.168.3.100 -> 192.168.2.2 (TCP) len=52 id=24338
TCP: 50393 -> 22 .S.... seq=71548dfe ack=00000000
[vs_0][fw_1] eth1:OE[124]: 192.168.202.80 -> 192.168.202.90 (50) len=124 id=7404

[vs_0][fw_1] eth1:id[124]: 192.168.202.90 -> 192.168.202.80 (50) len=124 id=33122

[vs_0][fw_0] eth1:id[52]: 192.168.2.2 -> 192.168.3.100 (TCP) len=52 id=0
TCP: 22 -> 50393 .S..A. seq=2a72dd30 ack=71548dff
[vs_0][fw_0] eth1:ID[52]: 192.168.2.2 -> 192.168.3.100 (TCP) len=52 id=0
TCP: 22 -> 50393 .S..A. seq=2a72dd30 ack=71548dff
[vs_0][fw_0] eth2:o[52]: 192.168.2.2 -> 192.168.3.100 (TCP) len=52 id=0
TCP: 22 -> 50393 .S..A. seq=2a72dd30 ack=71548dff
[vs_0][fw_0] eth2:O[52]: 192.168.2.2 -> 192.168.3.100 (TCP) len=52 id=0
TCP: 22 -> 50393 .S..A. seq=2a72dd30 ack=71548dff
[vs_0][fw_0] eth2:id[40]: 192.168.3.100 -> 192.168.2.2 (TCP) len=40 id=24339
TCP: 50393 -> 22 ....A. seq=71548dff ack=2a72dd31
[vs_0][fw_0] eth2:ID[40]: 192.168.3.100 -> 192.168.2.2 (TCP) len=40 id=24339
TCP: 50393 -> 22 ....A. seq=71548dff ack=2a72dd31
[vs_0][fw_0] eth1:o[40]: 192.168.3.100 -> 192.168.2.2 (TCP) len=40 id=24339
TCP: 50393 -> 22 ....A. seq=71548dff ack=2a72dd31
[vs_0][fw_0] eth1:O[40]: 192.168.3.100 -> 192.168.2.2 (TCP) len=40 id=24339
TCP: 50393 -> 22 ....A. seq=71548dff ack=2a72dd31
[vs_0][fw_1] eth1:O[40]: 192.168.3.100 -> 192.168.2.2 (TCP) len=40 id=24339
TCP: 50393 -> 22 ....A. seq=71548dff ack=2a72dd31
[vs_0][fw_1] eth1:OE[108]: 192.168.202.80 -> 192.168.202.90 (50) len=108 id=60012

[vs_0][fw_1] eth1:id[140]: 192.168.202.90 -> 192.168.202.80 (50) len=140 id=5328

A similar test when traffic is not sent into a VPN I see: id, ID, o and O.

Two questions:

- Do you see this too on your R80.20 GA environment?

- Can someone explain id, ID and OE?

Blog: https://checkpoint.engineer
5 Replies
Admin
Admin

Re: id, ID and OE inspection points in R80.20 GA?

Looks like id means "inbound decryption" (ID means leaving the inbound decryption module).

Thinking OE means "outbound encryption" (which would appear after O).

I'm guessing these changes are related to the changes made to SecureXL in R80.20.

RickHoppe
Silver

Re: id, ID and OE inspection points in R80.20 GA?

I would think so too but it seems the decryption module is always hit even on the gateway where traffic is supposed to go in the tunnel.


And with regular traffic (non-VPN) I see id and ID too instead of i and I. This is a bit confusing as I would now relate id and ID to VPN traffic.


Furthermore...where did ‘e’ go? Or did I miss it because of a wrong filter? Where we saw e and E on traffic between the IP’s of the VPN domains (in R80.10) we now see OE on the ESP packet between the peers.


sk30583 (and probably more SK’s) needs to be updated to reflect these changes in R80.20 if all of this is correct.

Blog: https://checkpoint.engineer
Admin
Admin

Re: id, ID and OE inspection points in R80.20 GA?

Again, I think some of the changes here are related to changes in SecureXL in R80.20, so the packets may appear to come out "differently" than they did before.

0 Kudos

Re: id, ID and OE inspection points in R80.20 GA?

Hi,

indeed those flags are related to VPN, regarding the id/D you will see them on clear traffic as we don't know if the traffic should be encrypted , this will happen only if you have VPN blade enabled.

regarding the SK we will update the SK and the usage command.

Re: id, ID and OE inspection points in R80.20 GA?

You can found more informations about fw monitor inspection points in this article:

R80.x Performance Tuning and Debug Tips – fw monitor

Inspection pointName of fw monitor inspection pointRelation to firewall VMAvailable since version
iPre-InboundBefore the inbound FireWall VM                            (for example, eth1:i)always
IPost-InboundAfter the inbound FireWall VM                               (for example, eth1:I)always
idPre-Inbound VPNInbound before decrypt                                          (for example, eth1:id)R80.20
iDPost-Inbound VPNInbound after decrypt                                             (for example, eth1:ID)R80.20
iqPre-Inbound QoSInbound before QoS                                               (for example, eth1:iq)R80.20
iQPost-Inbound QoSInbound after QoS                                                  (for example, eth1:IQ)R80.20
oPre-OutboundBefore the outbound FireWall VM                           (for example, eth1Smiley Surprised)always
OPost-OutboundAfter the outbound FireWall VM                              (for example, eth1Smiley Surprised)always

e

oe

Pre-Outbound VPNOutbound before encrypt                                        (for example, eth1:e)

R80.10

R80.20

E

OE

Post-Outbound VPNOutbound after encrypt                                           (for example, eth1:E)

R80.10

R80.20 

oqPre-Outbound QoSOutbound before QoS                                             (for example, eth1Smiley Surprisedq)R80.20
oQPost-Outbound QoSOutbound after QoS                                                (for example, eth1Smiley SurprisedQ)R80.20

or this article:

R80.x Security Gateway Architecture (Logical Packet Flow) 

Regards

Heiko