[Openswan Users] traffic only being encrypted one way

[Paul Wouters]

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

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 is why I asked for more information. Knowing whether you use KLIPS or NETKEY
on the sending end would help reduce the possible scenarios.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155