ICMP to L2TP 'WAN' IP fails

[iMx]

Hi there,

I have a cable connection with a dynamic IP, for that reason I also have an L2TP tunnel from another provider that provides static IP addresses over the tunnel.  At some point after 17.7.7 (I think, or there about) ICMP to the WAN IPs over the L2TP tunnel stopped providing a response, immediately after an upgrade.  Currently running 17.7.12.

I have the following rules permitting ICMP:

Code: [Select]

pass in  quick on l2tp1 reply-to ( l2tp1 c.c.c.c )  inet proto icmp from {any} to {(l2tp1)} icmp-type {echoreq} keep state label "USER_RULE"
pass in  quick on l2tp1 reply-to ( l2tp1 c.c.c.c )  inet proto icmp from {any} to $Host_Guest_WAN_IP icmp-type {echoreq} keep state label "USER_RULE"
The below is a dump from the l2tp1 interface, showing the response - a.a.a.a is an external server, b.b.b.b the WAN IP on the L2TP tunnel/interface:

Code: [Select]

12:05:24.304934 IP a.a.a.a > b.b.b.b: ICMP echo request, id 5384, seq 58, length 40
12:05:24.304959 IP b.b.b.b > a.a.a.a: ICMP echo reply, id 5384, seq 58, length 40
12:05:24.304970 IP a.a.a.a > b.b.b.b: ICMP echo request, id 5384, seq 59, length 40
12:05:24.304994 IP b.b.b.b > a.a.a.a: ICMP echo reply, id 5384, seq 59, length 40
12:05:24.305005 IP a.a.a.a > b.b.b.b: ICMP echo request, id 5384, seq 60, length 40
12:05:24.305030 IP b.b.b.b > a.a.a.a: ICMP echo reply, id 5384, seq 60, length 40
The below is a capture from the L2TP providers end (they provide the option to create 10 second pcaps from their portal), the response does not make it down the tunnel.

Code: [Select]

97 9.367539 a.a.a.a b.b.b.b ICMP 106 Echo (ping) request  id=0x10ea, seq=5/1280, ttl=57 (no response found!)
So far, I have tried:

- Disabling 'reply-to' on the rule.  When this happens the response does not go down the L2TP tunnel, i.e the response is not seen in the l2tp1 capture
- Tried setting a gateway to the L2TP tunnel on the rule, rather than default.  Did not resolve.

Only thing I haven't tried so far, as I need to get a maintenance window from the other half, is disabling shared forwarding - is this likely going to help? 

But as I say, this stopped post a 17.7.x upgrade, I think when I upgraded from 17.7.7 to 17.7.10.

Cheers,

Ed

[iMx]

Disabling shared forwarding did not resolve the issue, will look to raise a bug.