VPN prevents access to public facing NATs

[Dale_Lobb]

  I have a ClusterXL running R80.40 on open servers.  This cluster is the main Internet border gateway for my organization.

  On this cluster, I have over 200 site to site VPNs, about 2/3 of which are to non-CheckPoint peers.  In addition the cluster handles all of my organization's Internet access for about 7000 employees and inbound connections to numerous public facing web sites.  All of the web servers are contained within a cluster DMZ or are situated behind a global load balancer in the DMZ.  The DMZ uses a RFC1918 subnet and the cluster provides static one to one NAT for the IPs in the DMZ.  NAT IPs are in the same routeable subnet as the cluster's external addresses.  The external subnet is not in the cluster's encryption domain (although I understand that the cluster's external IPs are in the encryption domain by default).

  Here is the issue: Many of of the peer gateways also carry user traffic to the internet, and almost all of them NAT that traffic to the peer's external IP, just like we NAT outbound user traffic via HIDE NAT behind the cluster's external VIP.  However, none of those sites are able to access my organizations public facing web sites via the assigned NATs.  Attempts to do so go unanswered.  The connection attempts do not even produce any logs in SmartLog.  However, checks with "fw ctl zdebug drop" show the connections being dropped with the reason "Clear text packet should be encrypted".  The web site NAT IPs are definitely not in the encryption domain of the cluster, but the cluster does handle these connections from the peer via NAT to the DMZ.

  Is there any way around this that does not require having to re-engineer all the VPNs to handle the web site connections inside the tunnels?  That would be a nightmare and probably not even possible for many of the very small organizations we partner with.  I'm hoping I merely have something misconfigured somewhere.  I understand that communication in the clear directly between the cluster and the peers is prevented by having the cluster's external IPs in the encryption domain, but the web site connections are not destined for the cluster's external IPs.

Any ideas?   Or is this unpreventable?

[the_rock]

I think simple diagram would certainly help, but even without it, I have a gut feeling what is happening here. So that error message "clear text packet should be encrypted" logically indicates that firewall believes that those connections NEED to be encrypted, which logically tells me they are NOT part of the enc domain, like they should be, since Im pretty sure this is domain based VPN and not route based.

Something I would verify...since nat is obviously supposed to happen, please confirm that NAT option is not disabled inside the vpn community (last tab on the bottom left when you edit the community in smart console) and simple capture with -F flag for fw monitor would also help. Happy to assist you if you are allowed to do remote session. 

Also, IF you can send us simple network diagram, it would be useful, just blur out any sensitive info.

Cheers mate.

Andy

[KennyManrique]

Hi Dale.

As stated above, the message "Clear text packet should be encrypted" is because remote users are sending it traffic to your DMZ using the remote's GW external IP address.

Since you have VPN between sites, Check Point's default behavior is to encrypt the traffic between the external IP addresses of both Gateways, so your firewall is expecting to receive the traffic from the external peer encrypted. The remote non-check point gateway sends the traffic cleartext, so traffic is rejected reaching your firewall.

You can check Scenario 3 on sk108600 to solve this

[Dale_Lobb]

  @the_rock  , @KennyManrique  , thank you for the replies.

  Remote users are sending to devices in my firewalls DMZ that are NATted to addresses other than my firewalls' external addresses.  These NAT addresses are not part of my encryption domain. Sk108600 option 3 seems to indicate that you would use that method to exclude from the tunnel something that is already a part of the encryption domain.  In this case, the destinations are already not in the encryption domain.
 
  I have attached a drawing of the setup, using fake IP networks, but in the same fashion as my setup.  As shown in the drawing, I have a domain based VPN with a partner (actually, this situation exists for all of my VPN partners) that is functioning well.  The devices in my and my partner's encryption domains are communicating as expected.

    My system
        firewall external    200.0.0.1/24
        firewall internal    10.2.0.1/24
        encryption domain    10.1.0.0/24
        users            10.0.0.0/24    HIDE NAT: 200.0.0.1
        DMZ server        172.16.0.1/24    STATIC NAT: 200.0.0.10
       
    partner's setup
        peer external        300.0.0.1/24
        peer internal        11.2.0.1/24
        encryption domain    11.1.0.0/24
        users            11.0.0.0/24    HIDE NAT: 300.0.0.1
        DMZ server        172.17.0.1/24    STATIC NAT: 300.0.0.10
 
  The issue is connections from the partner's user community (shown by the RED arrow), which are using HIDE NAT behind his firewall address (300.0.0.1)  cannot access the server in my DMZ, which is statically NATted to 200.0.0.10, which is not my firewall's external IP (200.0.0.1), nor is it in my encryption domain.  This traffic does not show up in SMARTVIEW logs, but a "fw ctl zdebug drop" shows the connections being dropped with "Clear text packet should be encrypted".
 
  Interestingly, connections from my user community (shown by the GREEN arrow), which are using HIDE NAT behind my firewalls' IP (200.0.0.1) are able to connect to the server in the partner's DMZ, which is statically NATTed to 300.0.0.10 (the partner firewall's external IP is 300.0.0.1).  The checkpoint firewall is not making any VPN proposals, it's just sending the traffic "in the clear".

  I understand that the partners external IP (300.0.0.1) is considered to be part of the partner's encryption domain by checkpoint by default, but the destinations are not part of the checkpoint's encryption domain, so why does it think they need to be encrypted?

[the_rock]

Let me copy all this into notepad++, so I can read and "digest" it more carefully, to make sure Im not missing anything. I will read it on one screen and then look at your diagram on the other, so it makes sense.

Once I review it all, will update the post with my logic.

Cheers,

Andy

[the_rock]

@Dale_Lobb 

Here is my problem with your statement:

You wrote:

The issue is connections from the partner's user community (shown by the RED arrow), which are using HIDE NAT behind his firewall address (300.0.0.1)  cannot access the server in my DMZ, which is statically NATted to 200.0.0.10, which is not my firewall's external IP (200.0.0.1), nor is it in my encryption domain

Well, if you think about it, since this is S2S vpn tunnel and you mentioned that server is NOT part of your enc domain, it makes sense why fw is "throwing" you the error that packer SHOULD be encrypted, as it believes its supposed to go through the VPN tunnel.

Or am I missing something here?

Andy

[Dale_Lobb]

checkpoint  encryption domain <-->  peer encryption domain should be encrypted, I got that.

Checkpoint --> any other address, not encrypted

Peer --> any other address should also not be encrypted, regardless of if the checkpoint is forwarding the traffic

[the_rock]

checkpoint  encryption domain <-->  peer encryption domain should be encrypted, I got that.

Correct, BUT, based on your last post, that does NOT seem to be the case, as server in your DMZ is not in enc domain, or whatever IP its being natted to

Andy

[Dale_Lobb]

That's my point, the destinations are not in my encryption domain, and actually cannot be at this point, as contacting all 200 partners to arrange for VPN encryption domain changes and rules updates is not an option.

Most of the servers in the DMZ post date the VPN tunnels' inception by years, or even decades.

[PhoneBoy]

You have to exclude the peer IP from the encryption domain on your end.
That’s done by following steps in Scenario 3 of the following SK: https://support.checkpoint.com/results/sk/sk108600

[Dale_Lobb]

  Well, yes, I knew that was possible, but it only works for peers that have a static IP.  About 1/3 or our VPNs are to CheckPoint SMB devices in employees homes, which makes them DAIP systems and the home IP is variable, at the mercy of the ISP's policies.  When the SMB is lit up, other people (other than the employee's work PC behind the SMB) in the home cannot access any portions of my organizations web properties, such as their patient charts, public web sites, etc.

  I was hoping there was some more generic way to address the issue.

[the_rock]

Ouch, then doing that sk would not be so useful, as IP would need to be static. I honestly would open TAC case and get official CP answer to this issue, but sadly, your options seem limited. I want to be optimistic, but Im always very realistic too...

[Dale_Lobb]

  🙂  OK, thanks everyone for chiming in. 

[PhoneBoy]

I know in R81.20, there is a check box in a regular gateway object to exclude the external IP from the Encryption Domain.
Looks something like this:

Unfortunately, this checkbox is not available for SMB gateways (I checked).
Which means you're limited to the crypt.def hack or an RFE with your local Check Point office.