netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 


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