@FarNorth 

 

It does not broadcast across the tunnel.

As I wrote in my original post, I have attempted both broadcast and addressed packets

 

Because the tunnel is a separate network from the LAN.

And yet, I can communicate between the remote client, and the local servers.  TCP and UDP communication between the two networks is working correctly, as expected from hardware that is documented as providing VPN services. 

 

It is a LAN protocol.

L2TP isn't a LAN protocol, neither is TCP or UDP.

 

I think it is a problem with the protocol unless you can make it broadcast in the VPN subnet.

As I wrote in my original post, I have attempted both broadcast and addressed packets

 

I haven't done a packet capture at the remote end, but the ER706W is providing a local subnet with gateway 0.0.0.0: if the ER706W is working correctly, it should be passing broadcast packets through the tunnel. However,  as I wrote in my original post, I have attempted both broadcast and addressed packets.

 

And the client is getting an IP in the VPN subnet/

The VPN is working correctly. Machines on both sides of the tunnel, in their respective subnets, are communicating with each other.

 

========

At this point, some explanation of how IP on ethernet works.

I send a packet to 10.1.1.1. It goes through the tunnel. The ER706W does not know the MAC of 10.1.1.1, so it broadcasts an ARP packet. 10.1.1.1 replies with it's MAC. The ER706W sends the packet to the MAC (puts an ethernet packet on the LAN with the MAC in the ethernet packet address field).

 

I send a packet to 10.1.1.1. It goes through the tunnel. The ER706W already knows the MAC of 10.1.1.1, so the ER706W sends the packet to the MAC.

 

I send a packet to 10.1.1.1. It goes through the tunnel. The ER706W does not know the MAC of 10.1.1.1, so it broadcasts an ARP packet.  10.1.1.1 is sleeping so it does not reply. The ER706W drops the packet.

 

I send a packet to 10.1.1.1. It goes through the tunnel. 10.1.1.1 is sleeping. The ER706W already knows the MAC of 10.1.1.1, so the ER706W sends the packet to the MAC. It is a magic packet, so 10.1.1.1 wakes up.  How does the ER706W already know the MAC? Because I have made a static binding. I can see that ER706W lists the destination in it's ARP table. 

 

Networks that don't have tunnels don't pass unroutable (private address) TCP/IP packets. L2TP is a Layer 2 tunnel. It not only passes unroutable (private address) TCP/IP packets, it will pass IPX (Novel) or AppleTalk, or any kind of garbage packet you put through it.  Once the ER706W gets the packet out of the tunnel, the ER706W has to decide what to do with it. IP packets coming out of the tunnel should be directed to the next destination using the IP address. IP packets with a known IP address giving a known MAC should be sent out the ER706W LAN ethernet port, with the correct known MAC.

 

This appears to be working correctly for most IP packets coming out of the tunnel, but not for WOL magic packets I am attempting to send.  I route all TCP/IP packets to the tunnel (route 0.0.0.0), with exceptions for local network packets. I don't know the MAC for the final destination. The ER706W routes some packets back out the WAN, and packets with local IP addressing into the LAN.

========

 

WOL with static IP binding works OK with different hardware (my Billion and OpenBSD and Cisco routers), but not yet with my Omada ER706W. Perhaps there is a firewall rule? Maybe I've just typed something wrong? Has anybody had an luck with this? What have I missed?

  @FarNorth 

 

Have you tried using the broadcast address for the remote subnet in the WOL request. In this case 10.1.1.255.

AFAIK that should enable the packet to be sent as Unicast and to be routed across the VPN. The remote router should then translate the packet back to a multicast broadcast