- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: VPN Tunneled traffic is blocked - Address Spoo...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
VPN Tunneled traffic is blocked - Address Spoofing
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.