Validating Branch-to-branch IPv6 Connectivity

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Validating Branch-to-branch IPv6 Connectivity

So I have a bunch of Starlink services of varying models and configurations and service types, and I'm trying work through some options to get branch-to-branch tunnels working when both sides are behind CGNAT.

 

One such option is using IPv6, as it eliminates any NAT issues. I'm trying to understand how I can validate connectivity between two branches, both having globally routable IPv6 addresses configured by SLAAC (and DNS from DHCPv6) which both happily route to internet . These branches probably have connectivity to each other given they can both hit common internet hosts, but I can't actually validate it 100% for sure, as the IONs drop unsolicited traffic to their internet interfaces, including ICMP. I need to know for sure that it'll work before I go asking people to go moving cables, scheduling outage windows, etc.

 

I also can't validate it by actually spinning up the branch-to-branch tunnel, as that will just establish on IPv4, as IPv4 config is forced when enabling IPv6 on an interface (nothwithstanding the fact that removing IPv4 would drop the existing production tunnels).

 

We don't have netcat on the IONs, and curl hasn't been compiled with UDP support, so I can't try and coax some unintelligible refusal from 500 or 4500.

 

Thought of a Standard VPN of the IPSec flavour and just using the IPv6 address, but SCM won't accept IPv6 addresses in the peer IP field, so presumably unsupported.

 

Anyone got any clever ideas? Is there some hidden way to force IONs to respond to unsolicited ICMP? Blocking everything is a very sensible and secure default, but it's strange to not be able to override that behaviour. Hopefully I'm just missing something obvious.

 

(and yes, I know Starlink router will drop all inbound connections, too, this is why my two sites behind CGNAT don't work and I'm trying to validate connectivity with a site I know isn't behind a Starlink router, but unfortunately that one is also not behind CGNAT, so not a perfect test... then I have another issue with the IONs pulling an interface IP from SLAAC, but also from IPv6 PD, which is then breaking DNS lookups because the ION drops the Query response if it's sourced from the PD address instead of the SLAAC address, but let's leave that one until I can validate end to end connectivity)

1 accepted solution

Accepted Solutions

L2 Linker

You can enable ICMP on the Internet interfaces using the Advanced DACL menu: https://stratacloudmanager.paloaltonetworks.com/manage/advanced/dacl/sdwan 

 

As for IPv6 Branch to Branch tunnels, it should switch from v4 to v6 if the v4 endpoints are unreachable. 

View solution in original post

2 REPLIES 2

L2 Linker

You can enable ICMP on the Internet interfaces using the Advanced DACL menu: https://stratacloudmanager.paloaltonetworks.com/manage/advanced/dacl/sdwan 

 

As for IPv6 Branch to Branch tunnels, it should switch from v4 to v6 if the v4 endpoints are unreachable. 

Perfect, brilliant, simple. Thank you very muchly, that's exactly what I was looking for.

 


 

As for IPv6 Branch to Branch tunnels, it should switch from v4 to v6 if the v4 endpoints are unreachable. 


Yeah, that was my hope when I enabled IPv6 initially, then disappointment when it didn't work even though IPv4 also didn't work. But now I've been able to prove the Starlink routers are eating inbound connected (as expected and documented) so now I can work towards sending those routers to an early retirement.

 

Thanks again!

  • 1 accepted solution
  • 294 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!