Why they may not use this technology ? Even today irrespective of the
topology, traffic is intercepted by lawful agencies by using different
mechanism (port mirroring, etc...)
Thanks,
Yogendra Pal
Ericsson, India
On Wed, Mar 21, 2012 at 7:07 AM, Stephen Hanna sha...@juniper.net wrote:
Please
Sure. A VPN host (whether client or gateway) that is behind NAT is generally
unreachable from a random host.
To allow random hosts to get there, the VPN host needs to punch a hole in the
NAT by sending a binding request to a STUN server. The IP routable IP address
and port that it uses should
I don't think this is an all-or-nothing choice. You might want a mesh for VoIP,
but a star for HTTP, FTP and mail protocols. Or you may want a mesh within your
organization, but to trunk and inspect all traffic going somewhere else.
On Mar 21, 2012, at 3:37 AM, Stephen Hanna wrote:
Please
Protective Marking: UNCLASSIFIED
I think the important point here is that you should be able to set a policy to
determine which gateways, a given gateway is (or isn't) permitted to
communicate with. The interesting question is how granular that policy should
be (all or nothing -v- by
Thanks Yoav for elaborating it. I was just thinking around this 3rd
party broker to setup host-2-host tunnel. This broker can part of any
private cloud or mixed cloud in Cloud network (Can be added to solution).
Stephen,
To make p2p vpn scaleable, I think we should have simple solution with
Hi Yogendra,
I guess the question being raised here is slightly different.
The question is should all traffic be first sent to a central point
(Campus/ DC etc) inspected (IDS/ IPS/ Firewall) and then allowed to pass to
others peers or should there be a direct connection between the peers too -
On 3/21/12 11:30 PM, Yoav Nir wrote:
So if one or both of the VPN peers are behind NAT, we need some
3rd-party or parties to broken the NAT traversal. We need:
- a STUN (or STUN-like) server for punching the hole
- storage for the discovered address and port
In SIP these functions are done by
