tcpdump for site to site vpn traffic

[donnie]

Hi all,

I am using checkpoint 5600 with R80.1. 

I have configured site to site vpn over internet on this checkpoint firewall with my branch office which is working fine.

To check the traffic, i tried using "tcpdump -ni eth1 host 19.168.1.1" where eth1 is my external interface to the internet but i don't see any attempts "to and fro". My site to site vpn is working. I suppose i am not seeing any traffic using that command because the traffic is encrypted. How do i check using tcpdump or any tcpdump equivalent method so that i can verify the "to and fro" traffic in the event of troubleshooting other than verifying the tunnel (using "vpn tu" command) is up. TIA!

[HenrikJ]

I am not understanding the exact issue here.

You say the site-to-site tunnel is working?

Easiest way is just to check your normal logs, and see if the traffic you are looking for is being encrypted in the VPN community.

If you see the traffic, but it is not being encrypted in the community, then you'll have to verify that the VPN Domains in the community is correct, so the firewall knows to encrypt it into the tunnel.

I also recommend using fw monitor instead of tcp dump unless needed.
Remember disabling SecureXL before scanning though, as packet acceleration will hide most of the packets.
Please see this awesome post on the syntax (should be " in places where he has used ', just be wary of that).
https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/R80-20-cheat-sheet-fw-monitor/td-...

There's "FW Monitor SuperTool" which makes things easier, and also disables SecureXL if necessary.
https://community.checkpoint.com/t5/API-CLI-Discussion-and-Samples/FW-Monitor-SuperTool/td-p/60098

[Baasanjargal_Ts]

You can show your encrypted traffic through the site to site VPN. 

First. You can just search "VPN" on a "LOGS and Monitoring" section.

[HeikoAnkenbrand · Accepted solution]

Hi @donnie 

use the following CLI command to check the VPN network packets:

# fwaccel off
# fw monirot -e "accept(host=192.168.1.1);"
# fwaccel on

You can find more about fw monitor in my article:
R80.x - cheat sheet - fw monitor

"fw ctl zdebug" is a powertool that is not exhausted from being used with "fw ctl zdebug drop". There is not much to be found in Check Point KB or in the documentation. "fw ctl zdebug" is an R&D tool for testing software in development. Therefore, the insert should be used with care. It starts a debugging in the background until it is aborted with CTRL+C. On productive systems it can have a high performance impact. Furthermore, the debug buffer is not the largest.

You can also view this with the following command:

# fw ctl zdebug + monitorall  | grep -A 5 -B 5 "192.168.1.1"

More read here:
"fw ctl zdebug" Helpful Command Combinations

[chymmmy]

Hello

I have a VPN site-to-site

10.11.34.12 (client)<-> FW (201.21.22.12)  <- Internet -> (80.80.80.80)  <-> 10.222.23.22 (server)

In the inbound FW interface I see a client hello sent; but, I cannot see the server hello comming. (also I cannot see a drop with the # fw ctl zdebug | grep "10.11.34.12".

In the log show us a error
HTTPS Validation The probe was unable to establish a TCP connection to the destination
Description Bypassing request as configured in engine settings of HTTPS Inspection

How I can perform a fw monitoring, o packet capture to take an evidence that the client hello packet is sent through the VPN.

Note: The VPN is used for other services that It works fine.

[PhoneBoy]

The TCP connection is coming from the gateway itself and is a direct result of the SNI Verification we do for HTTPS traffic.
See: https://support.checkpoint.com/results/sk/sk163594
I presume you will be able to see whether or not it goes through the VPN in an fw monitor.
However, the source IP of the traffic will be the gateway itself, not the host who initiated the traffic. 

[chymmmy]

Thank you for your information

I understand that the entire packet from the secure gateway is src:201.21.22.12 and dst:80.80.80.80, both public IPs. But, inside that whole paket the packet src:10.11.34.12 to dst:10.222.23.22 is encapsulated.
I see the handshake, and the fin / ack.

But, I'm looking for a tool / method to see if the client hello is encapsulated in the whole packet, and the FW doesn't drop.
The idea is to have a some way to check process in the encasulation and see a evidence that the packet is sent.

Thank you

[PhoneBoy]

Again, using the IPs before VPN encapsulation, fw monitor is the correct tool.
It will show you the traffic as it goes through the various inspection points, including before the traffic is encrypted (Pre-Outgoing VPN).
I would expect the traffic to stop showing after it enters the VPN since the IPs will be different after encapsulation.

[Christopher__C2]

Run tcpdump filtering for the IP address of the VPN peer.  (assuming 19.168.1.1 you attempted filtering for is an internal host).

On the outside interface if the firewall you should see ESP packets to/from the IP addresses of the two VPN gateways, these are the encrypted and encapsulated packets. Possibly a few packets on UDP/500 for periodic key exchanges / updates, and a few when first establishing the tunnel.

But if you see 4-5 packets on UDP/500 every so often (maybe 30 seconds or so), and no ESP packets, it's usually down, there's a problem. (and if you don't see anything, most likely you have a mistake in your tcpdump command).