- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Route based to domain based VPN community conv...
- 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
Route based to domain based VPN community conversion
Hey guys,
Im fairly sure the only way to convert from route based to domain based community is either to delete it and set up brand new one OR change tunnel management option, remove VTIs on OS level, update topology and rules (if needed) and install the policy.
Or, is there another, maybe better way? Customer asked me this question, as they had so many issues with route based VPN tunnels (after probably 6-7 TAC cases and they went nowhere), so they want to try domain based community instead.
Thanks for any suggestions/ideas. Sadly, I dont have all the details, but from what I understand, it was mostly related to routing/failover between DR site and satellites.
Cheers,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm definitely curious about the problems they've seen with route-based VPNs. My experience is the exact opposite: route-based VPNs are so much better than domain-based that I'm amazed they aren't the default recommendation.
Going from route-based to domain-based is pretty easy. All it would take is setting up the encryption domain on one or both ends (depending on whether only one or both are set to use an empty group), removing the VTI from the CLI and firewall object topology table, then pushing policy. You definitely wouldn't need to tweak any rules, since route-based VPNs don't match the VPN community, so all the rules' VPN columns must already be set to "Any Traffic".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you @Bob_Zimmerman . I will inquire more about the issues. Honestly, I also never had any problems with route based tunnels, they seem to work so much better.
Will update once I get more details.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got bit more info...here is their response:
Failover is normally fine when initiated, however failback is usually a problem specifically when the link is utilized for extended period. If I failover straight away it seems to work ok.
I’m wondering if the tunnel expires during long periods and pings can’t make it across the tunnel when attempting to failback.
**************************************************************
I asked them for the network diagram that would make this even more simplified, but to me, sounds like when there is one fw with the issue or it has to be rebooted, failover to next one works fine, but then failback is where the issue occurs.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are they talking there about cluster failover or using dynamic routing to fail between two VTIs? Probably it needs a big ol' configuration review to make sure everything's up to spec.
To answer the question though you basically have to start fresh. Remove tunnel interfaces, remove them from the topology, set VPN domains on local gateway and interoperable devices, etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Im still waiting for all the details, but yes, Im talking about cluster failover/failback.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@emmap and @Bob_Zimmerman
I will speak with customer today about unrelated issue, so will ask them again about this. Sorry for the delay and thanks as always for helping.
Cheers,
Andy
![](/skins/images/AB448BCC84439713A9D8F01A2EF46C82/responsive_peak/images/icon_anonymous_message.png)