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