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
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
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
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
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
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