Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
SecurityNed
Collaborator
Jump to solution

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. 

Screenshot 2023-09-08 171507.png

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!

2 Solutions

Accepted Solutions
Martijn
Advisor
Advisor

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

View solution in original post

SecurityNed
Collaborator

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.

View solution in original post

13 Replies
PhoneBoy
Admin
Admin

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.

SecurityNed
Collaborator

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. 

PhoneBoy
Admin
Admin

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

Martijn
Advisor
Advisor

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

SecurityNed
Collaborator

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.

the_rock
Legend
Legend

I see the point @Martijn is making, I would definitely check into that as well.

Andy

Zolocofxp
Collaborator

You can also follow sk25675 and sk98241 to exclude traffic from being encrypted. 

the_rock
Legend
Legend

Definitely good SKs.

SecurityNed
Collaborator

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)


Untitled.png

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.

the_rock
Legend
Legend

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

SecurityNed
Collaborator

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.

SecurityNed
Collaborator

Thank you guys, I was able to troubleshoot it with the help of your inputs. Everything's working as intended now.


Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events