- CheckMates
- :
- Products
- :
- General Topics
- :
- Two Numbered VTI's between gateways managed by sam...
- 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
Two Numbered VTI's between gateways managed by same Security Management?
The scenario is the following:
- GW-A with R80.20, with two external connections for VPN
- GW-B with R80.20, with two external connections for VPN
- Both gateways managed by the same SMS
I already deployed redundant VPN using Route Based Probing, which let me choose between HA or LS among multiple VPN Links defined (interfaces). Also tested this using Service Based Link Selection, to distribute the traffic according to service name defined on SMS.
Now, for more optimal balancing purposes I need to select which networks will use a specific link. To accomplish this, the best way it's Route Based VPN with Numbered VTI. This approach lead me to some doubts that may not allow me to configure the scenario as I want (more than one VTI) mainly because both gateways are managed by the same SMS:
- At Numbered VTI configuration through GAiA Portal, the parameter PeerName is required. At interface fetch time on topology table, the only IP address that is fetched is the main object IP of PeerName previously configured. Altough this IP could be one of the external VPN address; how do I define the second VTI pointing to the other external VPN address?
- Is it possible to create dummy objects to overcome the PeerName parameter limitation? The main issue I see here is that the gateway objects will be duplicated and vpn may not work as expected since theoretically I will had to configure communities with the real and fake objects (idk if two or four communities in total). Also, again since both gateways are managed by the same SMS, by default the VPN uses certificates and I don't know how this will behave actually.
Anybody who has any suggestions on this? Any different approach to get VPN LS using networks instead of services?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you're supposed to configure an IP on the VTI interface, as described here: Configuring Numbered VTIs. You would then configure the routes in terms of that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dameon, thanks for the answer. It seems a bit difficult for my publication to be found/seen on the new forum.
I know how to configure VTI on both flavors, my doubt is if I can configure two numbered VTI tunnels between a pair of Gateways managed by the same SMS. The documentation does not contain any information about this; and for the way that numbered VTI must be configured pointing to a Gateway Name instead an IP address, becomes difficult for me to see if it's possible to accomplish what it's proposed on the post:
Also I wasn't able to found information about this (VTI redundancy) neither on SK or community posts.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anybody who has a suggestion on this topic?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did something similar with 1 hub and 2 spokes, where the spokes can communicate on their direct VTI or through the hub. The hub can reach spoke A through spoke B, if the direct VPN is down. I used a common community for all of them.
The traffic was controlled with BGP.
I agree that next hop IP would be much more appreciated here but it supposed to determine the peer IP based on the VPN selection settings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing your experience Alex.
On your case two spokes exists for the hub (three gateways total), so you had the advantage of having a different name for each spoke, simplifiying the VTI configuration.
Sadly there is no more than two gateways on my configuration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
In your case was it single management which manage all three gateways?
and how do they communicate with SMS? was it through external interface via internet or VPN?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you think about the communications involved running Mgmt traffic via the VPN can be problematic. The traffic itself is also already encrypted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kenny, did you ever solve this issue?
If not you could try to create a externally managed gateway with the IP of the secondary ISP, the actual gateway object has the object IP of the primary IPS line. Then you have 4 objects to create your VTI's with.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Marteen,
I'm still scratching my head with this.
I considered what you mention on the original question, create dummy objects for this purpose. However, as i mentioned, the object duplicity brings another considerations about tunnel establishment because both gateways are locally managed and I have serious concerns on weird behaviors.
By duplicating objects, this is what I think must be configured and my observations:
- Community using actual Gateways A and B (certificate based). No problem here, can be established using primary link.
- Community using actual GatewayA and dummy GatewayB's secondary address (Pre shared). GatewayA is defined with primary IP instead secondary, may cause issues.
- Community using actual GatewayB and dummy GatewayA's secondary address (Pre shared). GatewayB is defined with primary IP instead secondary, may cause issues.
- VTI interfaces are configured on Topology table, so both must exists on actual gateways.
- Cannot create a community using both Gateways dummy IP address (secondary link), since from management point of view dont own any of them to configure as Center Gateways because the lack of SIC.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We would appreciate very much if someone gave us some advice or recommendation to see if it is in any way possible 😀
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI.
Has any one experience like this senario, because we also need to establish vpn tunnel same as this, 2 gateways one management server each gateway having 2 VTIs. please advice.
Thank you,
Duminda Lakmal.
