Hi.
I think it should be more complicated than this. The suggested solution has a
dichotomy of either a full mesh or a start topology. The requirements should
cover scenarios such as a mesh within an organization connecting to a hub to
gateways outside the organization, or multiple hubs connect
Hi Yaov,
If I udnerstand correctly, what you seem to be talking about is a
Star-of-meshes or a mesh-of-star topology.
In my view this would be dealt with in 2 different iterations of the Mesh
VPN topology. So there would be a Mesh VPN for the Star topology and a
separate instance of the Mesh VPN
I'm not sure I understand the suggested resolution. The biggest barrier to
direct connectivity is that the responder may be behind NAT. Is this considered
a "routing issue"? In any case, there are protocols for getting to a responder
behind a NAT. They work well enough that VoIP solutions work
I might have put it like this if it wan't so similar to the way things are
configured on Check Point gateways :-)
It makes sense to me, but I'm not sure it covers all the use cases. Imagine a
topology that is entirely mesh, except for HTTP(S) traffic that is routed to a
central site because the
Hi Yaov,
I do see NAT traversal as a requirement and should be made part of the
problem statement. I however do not see it as a resolution of #213 or #214.
I see resolution for #218 and #211 talk about NAT.
Routing is about how packet is sent to the nexthop closer to the
destination, which is wha
Hi Yaov,
Perfect. We are on the same page here.
The way I see it is we treat it as a Mesh topology. The hub spoke tunnels
are permanent, with temporary and on-demand (based on data/ time/ activity)
spoke to spoke connectivity. This way we do not have the overload of excess
configurations on the s