- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: IPsec VPN Initiator
- 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
IPsec VPN Initiator
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Permanent Tunnel Mode Based on Dead Peer Detection
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for pointing that out, never really paid attention to it, good to know!
