Site-to-Site VPN and 'packet should not have been decrypted'

[VikingsFan]

New to CheckPoint firewalls and and helping troubleshoot an issue we're having on a new site-to-site VPN we have setup between us and JAMF for a MDM VPN solution.  Everything is working properly except for one server that we're trying to access and the only unique thing about this server is it's in one of the DMZs hanging off the firewall.  Everything else is on the internal network.  When I try and access the server over the tunnel, I get "According to the policy the packet should not have been decrypted" and it drops the packet.

Some basic info:

Gateways running Gaia R80.40.

Remote VPN Endpoint: 78.50.44.10

Local VPN Endpoint: 60.40.89.10

Trouble Server Real IP: 192.168.10.50

Trouble Server NAT IP: 60.40.89.50

VPN Domain: Main_Encrypt_Group

For the VPN community, the center gateway is the one I'm working on and the VPN Domain is a generic/general group that looks to be applied to all VPN communities and the gateway.  VPN routing is set to 'to center and to other satellites through center.'  NAT is disabled under advanced.  One VPN tunnel per gateway pair is checked.

One theory I have is that the server I'm having issues with is not in the 'Main_Encrypt_Group' and is why it's not staying encrypted.  However, this group is used for all other VPN communities and I was hesitant to add the DMZ server to this group without knowing the impact.

Am I able to change my JAMF VPN tunnel to a different group without impacting anything?  My thought was to clone the existing VPN Domain Group and create a 'JAMF_Encrypt_Group' and put the extra server in the group.  I then noticed under the 'Gateway Cluster Properties' that Under 'Network Management/VPN Domain' there is a 'set specific VPN Domain for Gateway Communities'.  Right now they're all set to 'according to the gateway'.  Is it as simple as just clicking on the JAMF one and then "Set" and choose my new VPN Domain Group?  It feels like that is what the solution might be but since I'm relatively new, I wanted to run it by here first.

Update:

Also, forgot one thing..  would I add the real IP AND the NAT IP or just the real?   We tried connecting both ways but got the encryption error.

[PhoneBoy]

Is the target server defined correctly in the remote encryption domain? (Assuming remote end is not using VTIs)

[VikingsFan]

Are you referring to this location?  The server that we're having issues with is NOT in the group that's under the VPN Domain section.  My idea was to clone this group and add the server to it and test.  Just wanted to run the idea by first if that seems to be the issue.

[Bob_Zimmerman · Accepted solution]

"According to the policy, the packet should not have been decrypted" always means the traffic arrived over a VPN with a remote peer, and either the source of the traffic is not in that peer's encryption domain or the destination of the traffic is not in the local encryption domain.

If you want the traffic to not use the VPN, you need to fix the configuration of the remote peer to cause it to not send the traffic in the VPN.

If you want the traffic to use the VPN, you need to fix the encryption domains defined in the management server for the local firewall. Either add the source IP (or network) to the peer's encryption domain or add the destination to your encryption domain.

There's a related message: "Received cleartext packet inside an encrypted connection". This one means the traffic arrived at the local firewall, but the source is in a peer's encryption domain and the destination is in the local firewall's encryption domain. The firewall is telling you it should have been received through a VPN with that peer, but it wasn't. This can be a routing loop (you receive and decrypt the packet, forward it on to some other router, then that router forwards it back to you; the second instance is dropped with this message), but usually means something needs to be removed from an encryption domain.

[VikingsFan]

Thanks Bob.  Sounds like my thinking of adding the server IP to my CheckPoint encryption domain is the way to go.  Just to confirm:

1. There's no issue having multiple groups to be used as encryption domains?  Our JAMF can have it's own group and the remaining VPN communities can have our default?

2. Does it matter if I use the NAT or real IP?  Same result?

[the_rock]

1) Thats right, no issue there.

2) Just to be on the safe side, if there is NAT involved, I would include both real IP and natted one into enc domain and make sure below is NOT checked within VPN community

Andy

 

[VikingsFan]

Hmmm.  we DO have the disable NAT checked.  I assumed that we would want that checked as we don't want the remote IP subnet hiding behind the firewall IP.  For example, if the JAMF mobile subnet is 10.250.250.0/24 and our local network is 192.168.0.0/16, we don't want their IPs hiding when we get logs, etc.  Unless I'm misunderstanding the use of that checkbox.

Thanks!

[the_rock]

Ok, so with that option checked, it simply means you would NOT be doing any natting inside community itself.

Andy

[VikingsFan]

Thank you.  We chose the subnet on the other side so it doesn't conflict with any subnet on our side and traffic would route like any other IP subnet on our network.  We also wanted to be able to build rules against the 10.250.250.0/24 network and see the IPs hitting internal servers without being behind a NAT.  Hopefully that makes sense and is what we're accomplishing.

[the_rock]

So, as @Bob_Zimmerman said, if you think about it, error you are getting "packet should NOT have been decrypted", what its really telling you is that packet SHOULD have been encrypted. That, without any doubt, ALWAYS points to quick mode negotiation, phase 2.

So, here is what I would quickly do on CP firewall and dont worry, this does not pose any cpu/memory problems, its very light debug.

By the way, what @PhoneBoy asked is JAMF enc domain, as it refers to remote server, local vpn subnets go in your cp gateway's enc domain, remote jamf ones go into their enc domain...makes sense?

Now, onto debugs.

From expert mode ->

vpn debug trunc

vpn debug ikeon

-generate some traffic for 1-2 mins

vpn debug ikeoff

Get ike.elg and vpnd.elg files from $FWDIR/log dir

examine and look for the IP you tested

Just to be sure, turn off debugs completely

fw ctl debug -x

fw ctl debug 0

Hope that helps and plese attach both files and IP you tested, can also have a look. Im jumping on a call with a colleague soon for Palo Alto, but can check regardless.

Cheers,

Andy

[VikingsFan · Accepted solution]

Hi everyone,

First thank you for assisting with this and getting me on track and eliminating any concern on my plan of action.  What PhoneBoy and Bob mentioned and I kind of thought already was the solution... I added the server to the encryption domain group on my side and that allowed the packet to stay encrypted end-to-end.  My tests are working now.

Thank you!

[the_rock]

Good job!

[the_rock]

Just remember CP fw enc domain should contain ONLY local subnets/hosts behind your fw and remote side would contain their subnets/hosts, thats it.

Andy

[VikingsFan]

Thanks Andy.  The JAMF side seems a little different but for their encryption domain you pick the /24 subnet that you want to run with and then they have a 'customer side' section of the tunnel and they say to just leave it at 0.0.0.0/0 and then locking it down with rules.  Sounds like what you described.

For the encryption domain, in this example JAMF, would you typically just have ALL local subnets that the firewall is connected to or only include the subnets/servers that you know the JAMF users would be connecting to.  Not sure what would be considered best practice.

[the_rock]

It depends on other VPN sites, but typically you just include local ones that users would connect to. You can change it here.

Andy

 

[VikingsFan]

Thank you.  Yep, that's exactly where I changed the new JAMF VPN Community.  Prior to this, there was just one generic encryption group being used.  I now have the generic still tied to all other VPN communities and then a new group just for JAMF.  It is just a clone of the generic one + the new server I was having issues with but I was thinking of pruning it down to just the handful of subnets that the users would talk to since currently there are 40-50 subnets in the list.

Thanks again.

[the_rock]

Again, you do NOT change remote sites enc domain here, ONLY local CP enc domain, depending on the remote community. Here, just to give you an example. Say you have 6 vpn tunnels, 2 with Cisco and 2 with Palo Alto and ok, say 2 with Fortigate, lets not leave out all major vendors : - )

So with Cisco, you ONLY want to advertise 10.10.10.0/24, with PAN 192.168.0.0/16 and with Fortigate 192.168.50.0.24, that should be reflected with proper groups in that screenshot I sent.

Makes sense?

For remote side, you define it below (in interoperable object settings) and thats ONLY local to other side, NOT Check Point

Andy

 

[VikingsFan]

Pretty sure we're on the same page. 🙂  See screenshots below of the current setup.  I have the new group for the local encryption domain. and the remote side is the JAMF_IPSEC_NET which is a /24 of our choosing on the JAMF side.

Showing the new local group for the vpn domain which has all the local FW subnets and problem server I couldn't connect to. On the bottom is the JAMF side and the /24 we created on the webpage in JAMF.Shows the JAMF IP endpoint and the /24 we created.On the JAMF side we pick the subnet we want for the local network. Remote side is 0.0.0.0/0

[the_rock]

Ok, maybe name Jamf_encryption_domain confused me lol. Just to make sure, even though thats the name, thats your LOCAL subnet(s) behind CP firewall?

Andy

[VikingsFan]

Possibly a misuse of our naming but the old group that was used for the cluster for the VPN Domain was called ENCRYPTION_GRP so I continued the name.

The 'JAMF_ENCRYPTION_DOMAIN' includes most of our internal subnets and servers but was missing the subnet of the server I was trying to reach initially and the reason for the initial post.  So I didn't mess with any production items, I copied the cluster VPN Domain group and made it the JAMF_ENCRYPTION_GRP and just added an additional two IPs (the real and NAT) of the server I was having issues with.

[the_rock]

Alright...NOW we are on the same page : - )

Cheers,

Andy