- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
I have Hub and Spoke Site to Site topology (both managed by same central management).
I am trying to understand, why always only the spoke initiated of tunnel creation?
I never saw that Hub was the initiator.
As we stated previously, the tunnel only comes up when one end needs to send traffic to the other.
If the traffic largely comes from the satellite, it is normal for the satellite to initiate the VPN tunnel.
The hub will only do if it has traffic for the satellite and the tunnel isn't already up.
This is all expected behavior.
VPN tunnels are usually open when one of the parties starts sending traffic to the other VPN domain. If you want them to be always up, set up permanent tunnels in the community properties.
I can only assume, in your case, it is only satellite sites initiate connections to the main site and not the other way around.
You right, only satellite sites initiate connections to the main site and not the other way around.
And that what I am trying to understand, why it is not in the opposite?
For example: if I reboot one of satellites, after it came up it will try to initiate the tunnel (and not the HUB).
After the reboot there is no traffic that need to go throug the tunnel.
So on which decision they determine who will start the tunnel initiation?
Note: I don't want the tunnel to be always up,
I am asking this question in order to understand how it is working.
As we stated previously, the tunnel only comes up when one end needs to send traffic to the other.
If the traffic largely comes from the satellite, it is normal for the satellite to initiate the VPN tunnel.
The hub will only do if it has traffic for the satellite and the tunnel isn't already up.
This is all expected behavior.
A VPN tunnel is only initiated when traffic needs to be sent down the tunnel.
A hub site would only initiate a connection to a spoke when it or a different spoke site have traffic for that particular site.
If a spoke site has a dynamic IP, the spoke must initiate the tunnel to ensure the hub knows what IP to send traffic to.
Let's assume I added new settlite to my current topology,
and there is no traffic which need to be sent down the tunnel
but there is still tunnel created and initiated by settlite.
Maybe there is something is missing from my understanding.
So without permanent tunnel enabled, the way it works really depends which side initiates the traffic, so regardless where traffic comes from, it would "kick start" the tunnel. I dont believe there is specific mechanism to force hub over spoke to be preferred, as far as I know.
As the guys said, make sure permanent tunnel option inside vpn community is enabled. Now, here is something to keep in mind. Enabling that is NOT enough on its own. You have to do below changes in guidbedit as well per below link:
this section (you need DPD value specially if its 3rd party device on the other side)
DPD can monitor remote peers with the permanent tunnel feature. All related behavior and configurations of permanent tunnels are supported.
To configure DPD for a permanent tunnel, the permanent tunnel must be in the VPN community. After you configure the permanent tunnel, configure Permanent Tunnel mode Based on DPD. There are different possibilities for permanent tunnel mode:
tunnel_test (default) - The permanent tunnel is monitored by a tunnel test (as in earlier versions). It works only between Check Point Security Gateways. Keepalive packets are always sent.
dpd - The active DPD mode. A peer receives DPD requests at regular intervals (10 seconds). DPD requests are only sent when there is no traffic from the peer.
passive - The passive DPD mode. Peers do not send DPD requests to this peer. Tunnels with passive peers are monitored only if there is IPsec traffic and incoming DPD requests.
Note: To use this mode for only some gateways, enable the forceSendDPDPayload registry key on Check Point remote peers.
To enable DPD monitoring:
On each VPN gateway in the VPN community, configure the tunnel_keepalive_method property, in Database Tool (GuiDBEdit Tool) (see sk13009) or dbedit (see skI3301). This includes 3rd Party gateways. (You cannot configure different monitor mechanisms for the same gateway).
In Database Tool (GuiDBEdit Tool), go to Network Objects > network_objects > <Name of Security Gateways object> > VPN.
For the Value, select a permanent tunnel mode.
Save all the changes.
Install the Access Control Policy.
Optional Configuration:
Starting in R81 if an interoperable device type is part of a VPN Community and Permanent Tunnels is set, the tunnel_keep_alive_method variable will be automatically set to "DPD" instead of "TUNNEL_TEST". This applies after upgrades as well. This is mentioned in scenario 5 of sk108600: VPN Site-to-Site with 3rd party.
Thanks for pointing that out, never really paid attention to it, good to know!
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 26 | |
| 16 | |
| 13 | |
| 12 | |
| 8 | |
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 5 |
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY