PC behind SMB

[Moudar]

Hi,

All traffic from our office site (SMB) is routed over VPN to our central site. This setup includes routing all internet-bound traffic, including DNS lookups, through the DC site.

It is route-based VPN configuration, where the encryption domain is empty, the DC gateway expects all traffic originating from our specific remote gateway (SMB) to be encrypted.

However, I'm encountering the error message "Clear text packet should be encrypted" specifically for traffic originating from a PC behind the SMB firewall.

Here are the details:

• Pinging from  the SMB device works without issues.
• The PC behind the SMB firewall has IP address 192.168.3.10 and its default gateway is set to 192.168.3.1, which is the SMB firewall itself.
• There is a static route configured to send traffic from the 192.168.3.0 network (SMB network) to the central site. At the central site, there is a corresponding static route to send the traffic back to the SMB network.

Despite these configurations, the PC behind the SMB firewall is unable to access the internet. All logs indicate that packets from this PC are being dropped with the message "Clear text packet should be encrypted."

This issue suggests that there might be a misconfiguration in how encryption is handled for traffic originating from the PC behind the SMB firewall, possibly related to VPN encryption settings, security policies, or routing. I'm seeking guidance on how to resolve this issue and ensure that all traffic, including internet-bound traffic, is correctly encrypted and routed through the VPN to the central site.

[PhoneBoy]

Sounds like this might apply: https://support.checkpoint.com/results/sk/sk182072 

[Moudar]

Does that apply on route based VPN ? My encryption domain is an empty group on both gateways!

[the_rock]

That does work (I had done it many times), though technically only remote side needs to have one.

Andy

[Moudar]

can you  please elaborate more on that

[the_rock]

Yes...so, local enc domain, you can just put a corresponding group containing subnets/hosts (whatever needed to be there) and then remote enc domain can be an empty group.

Setting in community if its subnet/hosts combo, or regardless what it is, make sure it says "per gateway"

Andy

[Moudar]

We are still discussing a star community setup, not a mesh configuration as mentioned in SK182072?

However, the admin guide states that both the central and branch sites should have empty groups to avoid any issues arising from these configurations.

[the_rock]

Thats right...just to make sure, error you get is still the same? Is it ONLY for one server?

Andy

[Moudar]

My PC behind the SMB, all its traffic is getting "drop" with that message. I did not test more, I will do it tonight 

[the_rock]

If enc domains are empty groups, then no reason why it should not work. Do ip r g command for that IP to see what it shows.

Andy

[PhoneBoy]

Best bet would be to consult with TAC here: https://help.checkpoint.com 

[emmap]

Which gateway is generating those logs, and what does your static route on the SMB gateway look like?

[Moudar]

I can see those logs on both gateways:

on SMS

on SMB

The static route on SMB

add static-route destination 0.0.0.0/1 nexthop gateway ipv4-address 192.168.4.10
add static-route destination 128.0.0.0/1 nexthop gateway ipv4-address 192.168.4.10

and one 0.0.0.0/0 to ISP

192.168.4.10 is the VTI address on central office

On central office there is no static route but 192.168.3.0 is known through OSPF.

OSPF on SMB has it and sends it to the other side

[the_rock]

Do ip r g command to that IP to see path its taking, simply to verify its 100% right.

Andy

ie  - > ip r g 8.8.8.8

[emmap]

Last time I tried this, the next hop of the routes had to be the VPN tunnel (in my case vpnt10) not the IP address of the tunnel peer. 

[the_rock]

In my experience, that makes sense IF you are talking about unnumbered VTIs, if its numbered, then DG ip would be something not used on the other side, but certainly NOT the peer IP

@Moudar Keep in mind this, as its IMPORTANT...if we are talking numbered VTIs, say your side has, I dont know, just as an example, 169.254.0.50 and other side is .51, thats ip you would use as default gateway to their network. However, its its UNNUMBERED vtis, then it goes based off the interface, so say eth0, for example and it would have exact SAME ip address.

Andy

If you need help, let me know. You can also check my post about it below, hope it helps.

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-tunnel-to-Azure/m-p/206179/emc...

[emmap]

In my test case it was a numbered VTI and the VTI IPs weren't an option when adding the route. SMB boxes seem to handle this differently to main train. 

[the_rock]

Not sure when it comes to SMB, but you are right, on regular Gaia, its most likely different.

Andy

[the_rock]

Hey bro,

That message in layman's terms, would indicate that it "sees" that packet as its supposed to be encrypted, rather than be sent in clear. I would double check encryption domain, because if its regular domain based tunnel, it all boils down to how vpn domains are configured, as opposed to route based tunnel, which is slightly different.

Andy