[Openswan Users] One Way Traffic Flow?

[Ben Batten]

Paul--

See inline ...

On 2/28/07, Paul Wouters <paul at xelerance.com> wrote:
>
> On Wed, 28 Feb 2007, Ben Batten wrote:
>
> > When I tweaked the conn that way I end up with INVALID_ID_INFORMATION
> and
> > INVALID_MESSAGE_ID errors.  Guessing as you said that NATT is jacked up
> and
> > probably on my 2.6.20.
>
> Are you doing PSK and IP based authentication?


This is actually cleared up, I'm back to seeing the SA established and
maintained but traffic (e.g., ping's) between the endpoints only go one way
(from each side).  I can see ping requests come in from one side or the
other but the receiving end doesn't ever send replies.  I can see the tunnel
negotiations go back and forth too.

To answer your question, I'm using x509 certs, not PSK.  I used the
subjectAltName on the HostB side to resolve an earlier ID issue, is that
what you meant by IP based authentication.



> > > Make sure you're not nat'ing packets destined for an ipsec tunnel
> >
> > No, in fact I think your comment about broken NAT is applicable here.  I
> was
> > under the impression that the NATT kernel patch was not necessary when
> using
> > netkey though (?).
>
> It isn't. Don't apply if you are not going to use klips.


OK, this isn't an issue.

> We're working in this configuration with the 2.4.7 version in this
> instance
> > with 2.4 kernels.  I tried the 2.4.8rc1 release and the NATT patch
> failed
> > with 2.6.20; I know the NATed side is working OK as I have another 2.4box
> > tunneling with it currently and it's working fine.
>
> I don't think it is the network. I think it is the configuration issue


Agree.  I'm just plainly missing some key piece(s); it's a fundamental
configuration or fundamental understanding issue.

I have a 2.4.9 klips system talking to the same NATed 2.4.9 klips system,
though.  The difference here being mainly the 2.6.20 Netkey endpoint.

Is there something additional I need to do on the Netkey side to get this
working?  Like use setkey or something?

> > conn HostA-HostB
> > > >  left=HostBpublicIP
> > > >  leftnexthop=HostBPublicDefaultGW
> > > >  leftsubnet=HostB/32
> > >
> > > That is almost always wrong. If you really just want a tunnel for the
> > > host, leave out the subnet. If you still get a message with some /32
> not
> > > known,
> > > you probably misconfigured NAT-T.
>
> Again, this is probably your problem. Remove the /32 and then fix the
> config


OK, this is out of the configuration.


> Yeah, see comment above.  My Linux 2.6.20 system appears to be the
> culprit.
>
> I don't think so.
>
> Paul
> --
> Building and integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070301/619e66f4/attachment.html