topic Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination in Firewall and Security Management

Site to Site Traffic inbound decrypt but no packets forwarded to destination

DekPlent — Thu, 27 Jan 2022 02:40:01 GMT

I am replacing some aging Checkpoint R71 appliances with 1590 appliances and am testing a very simple IPSEC VPN Site to Site VPN from a linux based StrongSwan user.

According to VPN Tunnels link and tcpdump, the VPN appears established with ESP sequence numbers increasing when I ping from the remote site inbound to the Checkpoint 1590. The traffic however does not leave the Chckpoint 1590 internal interface to the destination host and I cannot figure out why.

The log on the checkpoint shows:

and:

fw ctl zdebug + all |grep -A 1 "Monitor" | grep "192.168"

WAN:i0 (tcpt inbound)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i1 (vpn multik forward in)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i2 (vpn decrypt)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i3 (l2tp inbound)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i4 (Stateless verifications (in))[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i5 (fw multik misc proto forwarding)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i6 (fw early SIP NAT)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i7 (vpn tagging inbound)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i8 (vpn decrypt verify)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:i9 (fw VM inbound )[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:I10 (vpn policy inbound)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:I11 (vpn before offload)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;
WAN:I12 (fw offload inbound)[60]:192.168.236.100 -> 10.110.116.20 (TCP) len=60 id=53997;

I am really after ideas on how I can further debug this issue please, I have an access rule which allows 192.168.236.100 any TCP port to 10.110.116.20

Anyhelp hints or pointers would be greatly appreciated

Regards

Dek

Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination

DekPlent — Thu, 27 Jan 2022 17:51:25 GMT

Today I am seeing drops for the traffic and now :

fw ctl zdebug drop

;2401729;[cpu_3];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.236.100:33430 -> 10.110.116.20:22 dropped by vpn_drop_and_log Reason: According to the policy the packet should not have been decrypted;
@;2401741;[cpu_1];[fw4_1];fw_log_drop_ex: Packet proto=6 192.168.236.100:33430 -> 10.110.116.20:22 dropped by vpn_drop_and_log Reason: According to the policy the packet should not have been decrypted;
@;2401767;[cpu_3];[fw4_3];fw_log_drop_ex: Packet proto=6 192.168.236.100:33430 -> 10.110.116.20:22 dropped by vpn_drop_and_log Reason: According to the policy the packet should not have been decrypted;
@;2401819;[cpu_2];[fw4_2];fw_log_drop_ex: Packet proto=6 192.168.236.100:33430 -> 10.110.116.20:22 dropped by vpn_drop_and_log Reason: According to the policy the packet should not have been decrypted;

Is there a fundamental option which I have not clicked? In the older R71 just specifying the rule was part of a particular VPN site/ community was enough but I do not see the option to do this on the R80.20 webgui

Thanks again,

Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination

Timothy_Hall — Thu, 27 Jan 2022 18:08:59 GMT

Check your VPN domains for both peers; your peer's VPN domain is overlapping inappropriately with your own firewall. Also possible that the VPN domain is overlapping between two of your firewall's peers. Not sure if this command works on SMB appliances but try this from expert mode to highlight the overlap: vpn overlap_encdom communities –s.

Also possible the traffic is getting inappropriately NATed by the peer before placing it into the VPN tunnel, make sure "Disable NAT in VPN Community" is set in the VPN Community properties.

Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination

DekPlent — Thu, 27 Jan 2022 18:40:07 GMT

Thanks for your reply, Timothy

I will take a look at the possible NAT at the remote end

Meanwhile, the command that you suggested returned the following

# vpn overlap_encdom communities -s
arrange_objects: Not supported

No overlapping encryption domain.

Thanks again,

Regards

Dek

Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination

the_rock — Thu, 27 Jan 2022 18:50:03 GMT

From my experience, I see 2 most likely reasons for this...either NAT, or vpn domains mismatch.

Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination

DekPlent — Fri, 28 Jan 2022 10:58:24 GMT

So I have decided to use a completely different destination network but still seeing the decrypt log messages (open padlock) but no traffic is getting to the destination host.

What is the definition of a decrypt in this instance?

Are there any more inspection points after the decrypt that could implicitly drop the pkt without an actual drop showing in the logs? On the R71 solution I do see a decrypt for successful traffic and that is routed to the destination system successfully, but not on this 1590 running R80.20.

Thanks again

Regards

Dek

Re: Site to Site Traffic inbound decrypt but no packets forwarded to destination

DekPlent — Fri, 28 Jan 2022 11:39:16 GMT

Right it's working now. I had to define a destination network object 10.110.103.0/24 for the destination network despite the checkpoint already having a leg on this destination network and leaving the default option set in VPN -> Advanced :

Local encryption domain is defined automatically according to topology.

and the one liner command listed at https://community.checkpoint.com/t5/Security-Gateways/One-liner-to-show-VPN-topology-on-gateways/td-p/57975 already listing the local network as a valid encryption domain.

VPN Gateway > <External IP of Checkpoint>
Encryption domain
10.110.103.0 - 10.110.103.255

But hey that's one to remember.. Thanks for the input which inspired me to dig deeper in other areas etc.

Regards

Dek