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

[RickHoppe]

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?

[PhoneBoy]

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]

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.

[PhoneBoy]

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.

[Ilya_Yusupov]

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.

[HeikoAnkenbrand]

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

R80.x Performance Tuning and Debug Tips – fw monitor

Inspection point	Name of fw monitor inspection point	Relation to firewall VM	Available since version
i	Pre-Inbound	Before the inbound FireWall VM                            (for example, eth1:i)	always
I	Post-Inbound	After the inbound FireWall VM                               (for example, eth1:I)	always
id	Pre-Inbound VPN	Inbound before decrypt                                          (for example, eth1:id)	R80.20
iD	Post-Inbound VPN	Inbound after decrypt                                             (for example, eth1:ID)	R80.20
iq	Pre-Inbound QoS	Inbound before QoS                                               (for example, eth1:iq)	R80.20
iQ	Post-Inbound QoS	Inbound after QoS                                                  (for example, eth1:IQ)	R80.20
o	Pre-Outbound	Before the outbound FireWall VM                           (for example, eth1:o)	always
O	Post-Outbound	After the outbound FireWall VM                              (for example, eth1:O)	always
e oe	Pre-Outbound VPN	Outbound before encrypt                                        (for example, eth1:e)	R80.10 R80.20
E OE	Post-Outbound VPN	Outbound after encrypt                                           (for example, eth1:E)	R80.10 R80.20
oq	Pre-Outbound QoS	Outbound before QoS                                             (for example, eth1:oq)	R80.20
oQ	Post-Outbound QoS	Outbound after QoS                                                (for example, eth1:OQ)	R80.20

or this article:

R80.x Security Gateway Architecture (Logical Packet Flow) 

Regards

Heiko