VPN Tunneled traffic is blocked - Address Spoofing

[Johannes_Schoen]

Hi Community,

I got a annoying strange behavior:

Perimeter Checkpoint, Transfernet to Core Firewall with topoloy RFC1918 networks.

New VPN tunnel with a /24 net from 10.0.0.0/8 range.

Excluded tunneled network from address spoofing on external interface.

Created a Group RFC1918 networks with Exclusion of tunneld /24 network.

Set that group with exclusion to transfernet core-firewall interface

Traffic from VPN tunnel arrives, but dropped because of address spoofing.

What am I missing?

Help is much appreciated

Best Regards

Johannes

[Mark_Mitchell]

Hi Johannes, 

Can I ask which appliances you are configuring this on please? Have you defined your internet facing interface as an "External" interface?

Are both the perimeter and internal firewalls Check Point appliances?

I don't suppose you have a topology of the configuration to make it easier to visualise? And a copy of the log file entry if possible? 

Regards

Mark

[Johannes_Schoen]

Hi Mark,

I'm sorry for my late response - the notification mails were sacked as spam....

One of them is a 5900-HPP VRRP-Cluster with R77.30

The other one is a 3100 ClusterXL with R88.20

Both internal appliances are Checkpoint, our managment firewall is an interoperable device, but the drops are seen on Checkpoint side.

Topology is set to best practice (address spoofing enabled based on topology, internal nets, external net, dmz net und transfernets are marked)

This is the drop message:

Best Regards

Johannes

[Maarten_Sjouw]

Johannes,

On the Internet facing interface there is an option Do not check Spoofing from: in that field add a group, External_networks_over_VPN and add all remote VPN located networks to that group.

Sorry, missed that one line that you did already. You should double check on which interface the traffic is dropped been there to many times that the return traffic was dropped on the internal interface instead...

[Johannes_Schoen]

Hi Maarten,

I already excluded the tunneled network from monitoring side, but that didn't help either.

The ping/snmp traffic is dropped on the management interface (as seen in the screenshot above, received unencrypted packet should be encrypted)

[Mark_Mitchell]

Hi Johannes, 

Not a problem at all.  

It does look like it is a configuration issue. Could you check your encryption domains to ensure that all is setup correctly?

Have you attempted to complete a VPN debug yet?

How to generate a valid VPN debug, IKE debug and FW Monitor  

I appreciate that your VPN debug's will contain sensitive information. But if you needed a hand interpreting the outputs, just let me know. 

Regards

Mark

[Johannes_Schoen]

Dear Mark,

I think a vpn debug is not necessary.
The encryption domains and the tunnel itself is fine.

My only problem is, that the secondary node cannot be accessed from our encryption domain, because of drops from ipsec blade "Clear text packet should be encrypted".

I'm confused, because we have other situations with Check Point where exactly the same configuration is working.
I opened up a case with Check Point, but the answers take a long time so far.

[Danny]

Typically sk147493 will solve this issue. However, Check Point seems to have changed this behavior since R80.10 as we are having the same issue.