[Openswan Users] [NAT-T] one side thinks "established", the other...doesn't.

[Ferdinand O. Tempel]

On Fri, 2004-07-02 at 00:29, Paul Wouters wrote:
> > left:
> > conn nattest
> >   left=%defaultroute
> >   right=%any
> 
> Just a note, having a dynamic left and right can be tricky and might
> confuse pluto. You might be better of using an IP or hostname (or hostname
> in dyndns) instead.

I'll make it more explicit on the next test, tomorrow. It might be the
problem, though it does seem to work fine up until it's time to talk
ESP.

> >   rightsubnet=192.168.1.200/32
> >   authby=secret
> >   auto=ignore
> 
> Do not put rightsubnet= statements for the natted private space there.
> auth=ignore says this connection is not loaded? It seems you are withholding
> information :) You should have auto=add or auto=start.

To be able to catch a decent, trackable logging output I --add and --up
the connections manually :P This is just a testing connection, nothing
permanent.

I'm following the README for NAT-T, and Jacco's docs which both state
that this one of three methods of identifying the private address
*behind* the NAT is valid, and should work.

<quote>
  o Using Tunnel mode with roadwarriors, you will need to specify the
internal
    IP in the FreeS/WAN Configuration or use Virtual IP (see below).
      ex:
        right=%any
        rightsubnet=192.168.1.1/32
</quote>

Are you saying that both sets of documentation are outdated or wrong?

> > right:
> > conn nattest
> >   right=%defaultroute
> >   left=10.100.100.1
> >   leftnexthop=10.100.100.2
> >   authby=secret
> >   auto=ignore
> 
> Same ignore here.

Same reason here :P

> Note that both ends should include 192.168.1.0/24 in a virtual_private or
> subnetwithin decleration, and should NOT have the 10.100.100 in there.
> (usually people put all of 192.168/16 and 10/8 in there)

Actually, it's either rightsubnet *OR* virtual_private *OR*
subnetwithin...unless I read something wrong. Right?

Anyway, thanks for the prompt answer. I'm going to have a whack at one
of the other methods of identifying the NAT'ed client tomorrow. I'll get
back to you on this. If in the meantime anyone else has suggestions...

-- 
Regards,

Ferdinand O. Tempel

Your friendly neighborhood linuxops.net administrator.