[Openswan Users] traffic only being encrypted one way

[Bob Benstro]

On 3/16/07, Paul Wouters <paul at xelerance.com> wrote:
>
> On Fri, 16 Mar 2007, Bob Benstro wrote:
>
> > > Most often this is due to the vpn server not being the default
> gateway, and
> > > the local subnet sending the traffic for the vpn to the default
> gateway,
> > > instead of the vpn server.
> > >
> > >
> > I'm not sure what you mean.  It seems weird that you've removed from my
> > quoted material above, the text that provides information showing this
> isn't
> > the case.
>
> I did not see that information in your email.
>
> > Anyhow, as I mentioned, the traffic is indeed leaving the correctly
> routed
> > interface as it should be.   The only problem is that the traffic
> leaving
> > that interface is not encrypted.  It is, however, leaving the interface
> it
> > should be leaving, in order to reach the remote box.   My local subnet
> and
> > its default route is not in question, as I am performing all tests on
> the
> > VPN box itself, so no need to worry there.
>
> Okay. Are you sure the traffic leaves unencrypted? If you use KLIPS, that
> is
> indeed easy to see, just compare outgoing physical interface with ipsecX
> interface. With NETKEY, you don't get to see the encrypted packets before
> they
> leave your box, they are encrypted AFTER tcpdump can see them, so this
> cannot
> be proven using the sending box.



Hmm.  Well, I'm using NETKEY, I haven't patched my kernel or anything of the
sort.  There is no ipsecX device for me.

However, on the remote box, I can definitely see encrypted packets, although
I suppose these could merely be packets returning when I am pinging or
otherwise.  This lead me to believe that I should be able to see encrypted
packets, but fair enough.


Since if they were cleartext, they would go
> to some unknown private space and get dropped, you cannot see it on the
> receiving
> end either. But you might see encrypted packets arriving on the receiving
> end,
> which are never successfully decrypted for some reason (NAT, ipsec
> passthrough
> corruption, etc).



No, unfortunately there is absolutely no incoming traffic on the remote box
that I can see, when pinging/etc from the local to remote box, encrypted or
otherwise. :/


Then there is also the possibility you are in fact sending out encrypted ESP
> packets (which you can't see when using NETKEY), but some filter somewhere
> filters
> the ESP packets and they never arrive at the destination. Again, you would
> not be able to easilly distinguish this from the case they are never
> encrypted,
> send to a bogus router and dropped.



This could indeed be the case... but I suppose I would need to hookup a hub
and another box to watch for said case?  Can you think of an easier way?

Right now, if I tracedump to the remote box outside of the openswan setup
(direct external IP to external IP), I get a successful traceroute of about
9 hops, ending at the remote box.  If I tracedump using the extruded IP from
the remote box, it drops on the floor after 4 hops, which could support your
theory of a router dropping them along the way.  Blech. :/



This is why I asked for more information. Knowing whether you use KLIPS or
> NETKEY
> on the sending end would help reduce the possible scenarios.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070316/5af3011c/attachment.html