[Swan] xl2tpd does not respond
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:
ASSERTION FAILED at
c->spd.this.virt == NULL
So I rolled back to 3.15, and I still get:
EXPECTATION FAILED at
/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.
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:
> 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
More information about the Swan