From: "Michal Ruzicka" <michal.ruzicka@comstar.cz>
To: "Venkat Yekkirala" <vyekkirala@trustedcs.com>, <netdev@vger.kernel.org>
Cc: <dgoeddel@trustedcs.com>, <chanson@trustedcs.com>, <bphan@trustedcs.com>
Subject: Re: Multiple end-points behind same NAT
Date: Sat, 2 Dec 2006 20:15:05 +0100 [thread overview]
Message-ID: <007a01c71646$683a6e10$12a110ac@main> (raw)
In-Reply-To: 45709151.6060803@trustedcs.com
Hi,
although I'm not a kernel guru I think I've got something to say to this.
>
> I am wondering if 26sec supports NAT-Traversal for multiple
> endpoints behind the same NAT. In looking at xfrm_tmpl it's
> not obvious to me that it's supported, ...
You are looking at the rignt place indeed. Just to make you sure, there is
really no space to store the port infomation of the tunnel endpoints in the
xfrm_tmpl structure.
The structure xfrm_state (a kernel structuture for holding SA's) is a bit
different story though. Although the port information is not stored directly
in the structure either, there is the encap member pointing to a
xfrm_encap_tmpl structure which is used to hold the required information.
The consequences of this are:
1) The IKE dameon (or the key manager as it is called in the kernel context)
can't get the full infomation from the kernel required to be a successful
initiator in the case of multiple peers behind the same NAT. (Though you
might be able to get it working with a single peer behind the NAT if you
configure the port forwarding at the NAT box carefuly.)
2) If there was an IKE daemon which could be told the required port
information by some other means then directly by the kernel it should be
possible to make it work despite the deficiencies of the kernel. I don't
know if there is any IKE daemon capable of this, but I'm sure racoon can't
do that.
3) It is possible to get this working the other way around: If the boxes
behind the NAT were the initiators then it should work just fine at least if
tunnel mode was used. There are some problems with the transport mode but
even that can be made to work for certain scenarios.
Regards,
Michal
prev parent reply other threads:[~2006-12-02 19:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-01 20:32 Multiple end-points behind same NAT Venkat Yekkirala
2006-12-02 3:24 ` Herbert Xu
2006-12-04 15:52 ` Darrel Goeddel
2006-12-02 19:15 ` Michal Ruzicka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='007a01c71646$683a6e10$12a110ac@main' \
--to=michal.ruzicka@comstar.cz \
--cc=bphan@trustedcs.com \
--cc=chanson@trustedcs.com \
--cc=dgoeddel@trustedcs.com \
--cc=netdev@vger.kernel.org \
--cc=vyekkirala@trustedcs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).