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 be stored somewhere, in case some random VPN host wants to contact it. It has to be stored outside the VPN host itself, because that host is unreachable. 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 the SBC. So just like the #214 and #217 issues, we need a 3rd party to broker the host-2-host tunnel that we want to set up. It's tempting to assign this function to a hub gateway as the VPN host already has the ability to authenticate to it, but that should be part of the design, not the requirements Yoav P.S: Sorry if my SIP/RTP terminology is off. It's all based on a cursory reading of a Wikipedia article. On Mar 22, 2012, at 7:58 AM, yogendra pal wrote: 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 Ericsson, India +91-9686202644 On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir <y...@checkpoint.com<mailto:y...@checkpoint.com>> wrote: "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 traversal mechanism, perhaps using a hub gateway in place of the SIP SBC, then this should be part of the requirements. This mechanism is needed even if only one endpoint is NATted, otherwise we're constraining who the initiator has to be. Yoav On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote: > Another issue. Please comment on Suggested Resolution. > > Thanks, > > Steve > > -----Original Message----- > From: ipsecme issue tracker > [mailto:t...@tools.ietf.org<mailto:t...@tools.ietf.org>] > Sent: Tuesday, March 20, 2012 6:58 PM > To: yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>; > draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org<mailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org> > Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint > connectivity may not be possible > > #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be > possible > > In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible > if both endpoints are NATed. > > Suggested Resolution: Mention this in section 2.1. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@… | problem@… > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | Keywords: > Resolution: | > -------------------------+------------------------------------------------- > > Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1> > ipsecme <http://tools.ietf.org/ipsecme/> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org<mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > IƧ��[�(^rC�{S�֥I�.�+r �^�� _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec --
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
