Yoav == Yoav Nir y...@checkpoint.com writes:
Yoav direct endpoint-to-endpoint connectivity may not be possible
Yoav if both endpoints are NATed
Yoav Why? There are several protocols (SIP/RTP come to mind) that
Yoav manage endpoint-to-endpoint connectivity even when both are
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
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
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
direct endpoint-to-endpoint connectivity may not be possible if both endpoints
are NATed
Why? There are several protocols (SIP/RTP come to mind) that manage
endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't
IPsec endpoints do this?
If this requires some new NAT
I agree to what Yoav stated, that signalling part (SIP) and media part
(RTP) both SHOULD work even if there is NAT in the configuration today.
However, I could not get why we need to have new NAT traversal mechanism
using hub gateway, can you elaborate on this...
Thanks and Regards,
Yogendra Pal
Another issue. Please comment on Suggested Resolution.
Thanks,
Steve
-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:58 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #213:
