Some traffic is redirected to VPN tunnel without IPSec VPN Configuration

[Sarm_Chanatip]

Hi Everyone,

I have some case that is quite weird, my customer has Security Gateway R80.10 with HF T121 running at the moment.

The problem is when users that's behind Check Point does not get access to Public IP Address of Fortigate sometimes.

This only happens to Fortigate FW3 ( 203.xxx.xxx.138 ) refer screenshot below and there are no IPSec configuration of both sides

Here is the screenshot if the connectivity is being successfully to destination IP address, look at on column blade is showing firewall and https inspection. We do configure as a bypass for those IP public this is expected behavior 

But they sometimes can not get access to that web portal page due to the traffic is redirect to VPN tunnel, look at on column blade is showing VPN blade

This problem happens intermittent without a cause, I have already opened case to TAC but they can not find out something wrong as well

I ran zdebug drop command during the issue was occurring and below is output

[Expert@cpgateway:0]# fw ctl zdebug drop |grep 203.xxx.xxxx.138
;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=6 202.xxx.xxx.197:53651 -> 203.xxx.xxx.138:443 dropped by vpn_encrypt_chain Reason: encrypt drop;
;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=6 202.xxx.xxx.197:53651 -> 203.xxx.xxx.xxx:443 dropped by vpn_encrypt_chain Reason: encrypt drop;
;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=6 202.xxx.xxx.197:53651 -> 203.xxx.xxx.xxx:443 dropped by vpn_encrypt_chain Reason: encrypt drop;

From Access Control Policy, we have configured rule with source to dest and with all any service and https inspection rule with bypass for those Fortigate Public IP

I do not know the root cause of this case, does any one can help or guide me to check more and find the root cause ?

Really appreciate and thanks in advance. 

Regards,

Sarm

[PhoneBoy]

The TAC is the right place for this inquiry.

Please send me the SR number in a private message.

[Timothy_Hall]

Are there any VPN Communities that your Check Point gateway is a member of?  Is your Check Point terminating any Remote Access VPN tunnels?  If the answer to both questions is no (and you are quite sure about that), uncheck the "IPSec VPN" blade product checkbox on the firewall and run enabled_blades on the firewall after reinstalling policy to verify.  The IPSec VPN blade seems to be on by default in most installations, even when it is not really needed.

If there are other tunnels and you can't uncheck it, the only situation that would cause an encrypt action is the source IP falling within your firewall's VPN domain and the destination IP address falling into the VPN domain of a VPN peer's object.  Is there any kind of object representing 203.xxx.xxx.138?  If so what kind of object is it?  It should just be a simple host, not an interoperable device, externally managed gateway type, or Check Point host.  The only other situation that could cause this would be a VPN Tunnel Interface being present in a route-based VPN setup which you are pretty unlikely to have present.

Might also be interesting to show all known VPN domains in your config with the tool below, the 203.xxx.xxx.138 address of the Fortinet should NOT appear anywhere in the output:

Show VPN Routing on CLI 

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

[Sarm_Chanatip]

Hi Timothy

Sorry for late replying, I just gathered all of information and screenshots to you and please see answers of your questions below

Are there any VPN Communities that your Check Point gateway is a member of?

-   Yes, there is only Remote Access VPN

Is there any kind of object representing 203.xxx.xxx.138? If so what kind of object is it? 

- It's just normal host object

Regarding of VPN domain, please see screenshot below

Below is an example of log when is not able to get access the destination IP address

[Timothy_Hall]

OK it looks like the Check Point is inappropriately trying to encrypt that traffic into a VPN tunnel associated with the RemoteAccess VPN Community.  My guess based on this limited information is the following:

1) When there is no one behind Fortigate FW3 currently doing a Remote Access VPN to the Check Point, the User can get access to the Public IP Address of Fortigate FW3 just fine, the traffic goes in the clear.

2) When there *is* someone behind Fortigate FW3 currently doing a Remote Access VPN to the Check Point, their Remote Access VPN traffic leaving the Fortigate FW3 is NATted to the same external IP address in use by the Fortigate FW3 for its portal.  As such, when a User at the Check Point site tries to initiate a connection the Public IP Address of Fortigate FW3, there is already an existing VPN tunnel with that address so the Check Point thinks it needs to be encrypted.  Unfortunately that is not the case so the encryption fails on the Check Point side.

Solution: use a different IP address to NAT outbound connections initiated from behind the Fortigate FW3 (such as Remote Access VPN connections) other than the Fortigate FW3 external interface 203.xxx.xxx.138 if possible. 

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30