- CheckMates
- :
- Products
- :
- General Topics
- :
- Traffic is suddenly encrypted by VPN
- 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
Traffic is suddenly encrypted by VPN
Hello Checkpoint Community,
We have this unusual behavior in our client's instance wherein traffic is suddenly encrypted through VPN when it shouldn't.
We honestly don't know why this happened, as there were no changes performed.
Does anyone have any experience in this and could give us some insight.
Thanks!
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The VPN log mentions tcp-high-ports as the service and the non-VPN log mentions TCP-9001 as the service. Can you check on what rule the VPN is hit? And check on what rule it should hit?
Did you changed 'Match for Any' in the mentioned services so traffic is hitting another rule than expected?
Maybe you can take a look at the Audit log to see what was changed after September 6th.
Regards,
Martijn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I actually found a reason as to why this happened. There's overlapping internal domains in both of my clusters, and unfortunately this traffic is being routed towards the other Firewall (NGFW Pair 1) instead. The correct behavior should be that it's going to be routed to its own Firewall (NGFW Pair 2). This has been now addressed.
Anyways, I created a policy to address this, and everything works smoothly now. I might have created a not-so-specific policy and that's why for some reason it keeps on routing the traffic to NGFW Pair 1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have a route-based VPN (with VTIs) configured here?
You'd probably need to dig into the log entries (the full log cards) to see why the rulebase logic changed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When opening the log cards, it just says that it's encrypted. But yeah I do think I have a route-based VPN.
I do noticed that in the log card, the traffic is routed to an IPsec VPN peer for some reason, which shouldn't be the case since I didn't define any routes that would do such action.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it all static routes or are dynamic routes used?
Either way, it appears that routing changed somewhere.
This would probably require investigation from the TAC: https://help.checkpoint.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The VPN log mentions tcp-high-ports as the service and the non-VPN log mentions TCP-9001 as the service. Can you check on what rule the VPN is hit? And check on what rule it should hit?
Did you changed 'Match for Any' in the mentioned services so traffic is hitting another rule than expected?
Maybe you can take a look at the Audit log to see what was changed after September 6th.
Regards,
Martijn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will check this as soon as I'm on site tomorrow. But I do remember its "Match Any".
There's no changes to the rule as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see the point @Martijn is making, I would definitely check into that as well.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can also follow sk25675 and sk98241 to exclude traffic from being encrypted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Definitely good SKs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Everyone,
To add, I just found a blocked rule regarding this which is unusual. It shouldn't be communicating to my other NGFW pair but it seems it is (via VPN)
I'm currently checking the SKs provided by @Zolocofxp, while checking @Martijn's suggestion
Will update you guys once there's improvements. Thank you so much for the help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yea...so that message packet should not have been decrypted really means it SHOULD have been encrypted, ie firewall "thinks" it should go through VPN.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I actually found a reason as to why this happened. There's overlapping internal domains in both of my clusters, and unfortunately this traffic is being routed towards the other Firewall (NGFW Pair 1) instead. The correct behavior should be that it's going to be routed to its own Firewall (NGFW Pair 2). This has been now addressed.
Anyways, I created a policy to address this, and everything works smoothly now. I might have created a not-so-specific policy and that's why for some reason it keeps on routing the traffic to NGFW Pair 1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good job!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you guys, I was able to troubleshoot it with the help of your inputs. Everything's working as intended now.