[Openswan Users] Openswan with L2TP/IPsec
bob at computerisms.ca
Sat Dec 18 15:49:29 EST 2010
Never having experimented with your scenario, I am likely way off base
here, but if your left and right are on the same subnet, I might expect
nothing to enter the tunnel.
My premise is thus; when a packet leaves the server/client destined to
the opposing end, it will consult the routing table. The first thing it
will find is a route to subnets it is connected too, for example
192.168.0.0/24. So if the opposing end is in that subnet, it will send
the packet out that route (ie, not the tunnel). Any further routes in
the table to the opposing end will not be consulted, therefore the
packet will not enter the tunnel because by the time it would have found
the route, it is already gone. If the route to the client is not found
on the subnet the interface is attached too, then it will proceed
further down the table till it finds the route that leads through the
If the two boxes are on different subnets, then this is a very bad
guess. If they are on the same subnet, then this is just a thought on
what the problem might be...
On Sat, 2010-12-18 at 13:02 +0200, Kevin Wilson wrote:
> I sniff with wireshark in the interface on which 192.168.0.10
> I sniff all the traffic without any filter such as destination or source.
> I don't see any ESP packets. I expected some ESP traffic.
> I suspected that something is wrong with the setup as described in
> my post, but it seems to me that there is no error there.
> So I am still confused and do not know what is wrong here
> and why don't I see ESP packets at all.
> Any idea?
> On Fri, Dec 17, 2010 at 9:21 PM, Paul Wouters <paul at xelerance.com> wrote:
> > On Fri, 17 Dec 2010, Kevin Wilson wrote:
> >> I tried to test a simple scenario of Openswan with L2TP/IPsec (of the
> >> openl2tp project) in a lab.
> >> protostack="netkey"
> >> I expected the traffic from .192.168.0.10, to 192.168.0.20 to be ESP
> >> encrypted, as a result
> >> of using Openswan with the /etc/ipsec.conf above, but sniffing
> >> with wireshark shows it is not. Any idea why ?
> > You know netkey has limitations with tcpdump? You can not sniff outgoing
> > encrypted packets. So verify on both ends that you see incoming crypted
> > packets.
> > Paul
> Users at openswan.org
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
bob at computerisms.ca
Network, Internet, Server,
and Open Source Solutions
More information about the Users