[Swan] xl2tpd does not respond

[Bob Miller]

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?