[Swan] xl2tpd does not respond

Bob Miller bob at computerisms.ca
Fri Feb 26 04:00:56 UTC 2016

hm, this is interesting.

Seems I can crash pluto quite reliably, looks like it was reported here:


the error is:

c->spd.this.virt == NULL

So I rolled back to 3.15, and I still get:

/usr/src/libreswan-3.15/programs/pluto/ikev1.c:2843: r != NULL

to be very sure, I did a rm -rf /usr/local/sbin/ipsec 
/usr/local/libexec/ipsec and reinstalled, both versions give same results.

I have removed all but the l2tp conn from my ipsec.conf.  It is the same 
as a dozen+ other config files I have to compare against.  so I can say 
for sure this is something to do with the l2tp conn.

conn rw-l2tp-withnat

conn rw-l2tp-nonat

On the other hand, if I remove the l2tp conn and just leave the two 
net-to-net conns, pluto runs without error (or apparently any problems).

hmph.  the investigation continues...

On 16-02-25 04:38 PM, Bob Miller wrote:
> Hi,
> Sorry to pester on this topic again, but I am spinning my wheels.  maybe
> someone can point out error in my thinking...
> As a recap, I have added a 2nd internet connection and lan to the
> existing firewall.  VPN was working fine before.
>> I tried loading libreswan and xl2ptd on the 2nd internet connection,
>> just to see what would happen, and discovered an oddness; it seems I
>> cannot ping from the 2nd connection to IP addresses within my ISP's
>> range.  can ping the gateway and outside the service area.  would seem
>> something routing-wise is wobbling, might be the source of the problem...
> I trace this down to a missing ip rule command, and all interfaces are
> working as expected now.  I have added a routing table, and set a fwmark
> so all traffic from the 2nd lan uses the 2nd routing table and goes out
> the 2nd internet connection.  both internet connections are on the same
> subnet, however they both respond on the external and internal side as
> expected, that is to say I got it all configured so traffic doesn't show
> up on one connection and leave on another.  At least that I can find.
> I have also upgraded to the latest libreswan 3.16, but I am still using
> the original xl2tpd-1.3.1.
> I have set ipsec saref = no in xl2pd.conf, and compared it closely with
> a working solution, and find nothing amiss.  I have enabled all debug
> options, but since there is no connection there is no debug information.
> xl2tpd is listening on the correct IP address and port 1701, and can
> receive traffic sent via netcat.  I can TRACE this in iptables, dump it
> on eth0, and record it on stdout when I run xl2tpd with -D.
> I have two net-to-net tunnels up and running, all traffic passes fine
> and the tunnels are stable.  When I connect the road warrior, I also see
> "IPsec SA established tunnel mode", but when deleting the state, it
> reports "ESP traffic information: in=0B out=0B".
> This smells like iptables, but port 1701 is open to regular traffic, and
> net-to-net tunnels come up.  Why/how could iptables block port 1701 from
> the roadwarrior's tunnel?
> I can't seem to trap any udp/1701 traffic in iptables anywhere when
> connecting from the roadwarrior, I have tried at every stage in the
> nfpacketflow diagram, as well as using TRACE from the raw table, it
> really seems to me that the l2tp traffic is not exiting the tunnel.
> I can confirm that the windows machine does send l2tp to another firewall.
> For grins and giggles I enabled plutodebug=all, but I see nothing
> interesting there.
> The only other thing I can think of that could play into it is
> protoport.  I currently have both sides set to 17/%any, but have tried
> all combinations of 17/0, 17/1701, and 17/%any.
> Does anyone have any suggestions on how I can find out where this l2tp
> constipation lives?
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan

More information about the Swan mailing list