• February 21, 2020, 06:53:48 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Author Topic: WakeOnLan (WOL) over L2TP tunnel from Windows 10 - Edited !!  (Read 125 times)

zEnterHacker

  • Level 1 Member
  • *
  • Posts: 9
WakeOnLan (WOL) over L2TP tunnel from Windows 10 - Edited !!
« on: February 12, 2020, 08:47:53 AM »

Hi,
I'm trying to find a setting on the DSR-250 (FW 3.12_WW) that allows a WakeOnLan (WOL Magic Packet on Port 7) to be sent from a roaming Windows 10 L2TP client and passed on to DSR-250 LAN. I have other firewalls where this works out of the box via L2TP, but I think some hidden rule (or missing policy with-in the DSR-250) blocks this UDP broadcast from the L2TP client.

Using the web Interface I see no options to set up polices for the actual L2TP tunnel to the LAN. I would expect everything to go through the tunnel (Full Tunnel Mode). I can ping, UVNC control, browse etc... local PCs  on the DSR-250 LAN via L2TP, but the WOL magic packet is not routed through the tunnel. I set up my roaming L2TP tunnels on the Windows 10 clients exactly the same way for the DSR-250 as for another firewall that allows WOL packets to flow through the tunnel.

I might just be missing something simple here - but I'm lost.
Below is a snippet from the DSR-250 log file around a roaming L2TP WOL request :o:

Help is apreciated  8)
Best regards
zEnterHacker

VPN DSR-250N racoon 1931 - - Responding to new phase 2 negotiation: 89.xxx.xxx.xxx[0]<=>5.vvv.vvv.vvv[0]
VPN DSR-250N racoon 1931 - - Using IPsec SA configuration: anonymous
VPN DSR-250N racoon 1931 - - No policy found, generating the policy : 10.zzz.zzz.zzz/32[1701] 89.xxx.xxx.xxx/32[1701] proto=udp dir=in
VPN DSR-250N racoon 1931 - - No policy found, adjusting source address for generating the policy incase of NAT-T in Transport Mode: 5.vvv.vvv.vvv/32[1701] 89.xxx.xxx.xxx/32[1701] proto=udp dir=in
VPN DSR-250N racoon 1931 - - Adjusting peer's encmode 4(4)->Transport(2)
VPN DSR-250N racoon 1931 - - an undead schedule has been deleted: 'pk_recvupdate'.
VPN DSR-250N racoon 1931 - - [IPSEC_VPN] Purged IPsec-SA with proto_id=ESP and spi=1863878172(0x6f18861c).
VPN DSR-250N racoon 1931 - - Unable to send SMS
VPN DSR-250N racoon 1931 - - Unable to send Trap
VPN DSR-250N racoon 1931 - - IPsec-SA established[UDP encap 65385->4500]: ESP/Transport 5.vvv.vvv.vvv->89.xxx.xxx.xxx with spi=16644669(0xfdfa3d)
VPN DSR-250N racoon 1931 - - Unable to send SMS
VPN DSR-250N racoon 1931 - - Unable to send Trap
VPN DSR-250N racoon 1931 - - IPsec-SA established[UDP encap 4500->65385]: ESP/Transport 89.xxx.xxx.xxx->5.vvv.vvv.vvv with spi=2542734746(0x978f0d9a)
VPN DSR-250N racoon 1931 - - Unable to send SMS
VPN DSR-250N racoon 1931 - - Unable to send Trap
VPN DSR-250N - - - - IKE: Responding to new phase 2 negotiation: 89.xxx.xxx.xxx[0]<=>5.vvv.vvv.vvv[0]
VPN DSR-250N - - - - IKE: Using IPsec SA configuration: anonymous
VPN DSR-250N - - - - IKE: No policy found, generating the policy : 10.zzz.zzz.zzz/32[1701] 89.xxx.xxx.xxx/32[1701] proto=udp dir=in
VPN DSR-250N - - - - IKE: No policy found, adjusting source address for generating the policy incase of NAT-T in Transport Mode: 5.vvv.vvv.vvv/32[1701] 89.xxx.xxx.xxx/32[1701] proto=udp dir=in
VPN DSR-250N - - - - IKE: Adjusting peer's encmode 4(4)->Transport(2)
VPN DSR-250N - - - - IKE: less key length proposed, mine:128 peer:256.  Use initiaotr's one.
VPN DSR-250N - - - - IKE: an undead schedule has been deleted: 'pk_recvupdate'.
VPN DSR-250N - - - - IKE: [IPSEC_VPN] Purged IPsec-SA with proto_id=ESP and spi=1863878172(0x6f18861c).
VPN DSR-250N - - - - IKE: Unable to send SM
VPN DSR-250N - - - - IKE: Unable to send Tra
VPN DSR-250N - - - - IKE: IPsec-SA established[UDP encap 65385->4500]: ESP/Transport 5.vvv.vvv.vvv->89.xxx.xxx.xxx with spi=16644669(0xfdfa3d)
VPN DSR-250N - - - - IKE: Unable to send SMS
VPN DSR-250N - - - - IKE: Unable to send Trap
VPN DSR-250N - - - - IKE: IPsec-SA established[UDP encap 4500->65385]: ESP/Transport 89.xxx.xxx.xxx->5.vvv.vvv.vvv with spi=2542734746(0x978f0d9a)


Edit after investigation:
Edit:
Assume the LAN PC to be woken is 10.0.0.128 (Behind the Firewall)
The WOL packets below all wake up the PC when sent from a device on the local LAN:
OK:  wolcmd 1234567890AB 10.0.0.255 255.255.255.0 7
OK:  wolcmd 1234567890AB 10.0.0.128 255.255.255.0 7
OK:  wolcmd 1234567890AB 10.0.0.128 255.255.255.255 7


Testing the same WOL commands through a L2TP tunnel and with a WOL logger running on 10.0.0.128 reveals:
BAD: wolcmd 1234567890AB 10.0.0.255 255.255.255.0 7
BAD: wolcmd 1234567890AB 10.0.0.128 255.255.255.0 7
OK:  wolcmd 1234567890AB 10.0.0.128 255.255.255.255 7

So only by NOT using broadcasted WOL packages (subnet 4 x 255) the DSR-250 L2TP tunnel allows the WOL packet to reach 10.0.0.128 because it is considered a "normal" IP packet designated for 10.0.0.128.

Now powering OFF 10.0.0.128 and testing the usual WOL packets via L2TP in order to se if the PC wakes up reveals:
BAD: wolcmd 1234567890AB 10.0.0.255 255.255.255.0 7   (same as when powered ON)
BAD: wolcmd 1234567890AB 10.0.0.128 255.255.255.0 7   (same as when powered ON)
BAD: wolcmd 1234567890AB 10.0.0.128 255.255.255.255 7 (expected - se comment)

Comment:
Powering OFF 10.0.0.128 means that 10.0.0.128 will no longer respond to ARP requests from the DSR-250 when trying to WOL via a "normal" IP packet designated for 10.0.0.128.

Conclusion:
The L2TP of the DSR-250 claims that when You connect to the firewall via VPN (including L2TP) then you can do the same things - i.e. communicate - as if You were connected to the LAN.
This I'm afraid is NOT the whole truth!

I believe that the DSR-250 does NOT behave like f.i. D-Link DFL-210/870/1660/2560 NetDefend Security UTM Firewalls (Clavister core).
In these UTM firewalls You define a L2TP tunnel (equal to the DSR-250) BUT then You define a policy that allows various services (in my case all_services) to float from the virtual L2TP_interface to the LAN_interface and that perfectly routes the WOL broadcast packets on to PCs connected to the LAN.
In other words WOL works through the tunnel as expected.

Question: Why would anyone specify the DSR-250 NOT to route WOL broadcast packets through L2TP when other UTM firewall does this by default when allowing all-services in a tunnel?

And the ultimate question still stands:
How can I set up the DSR-250 to allow WOL L2TP packages to be broadcasted on to the LAN?
 
Best regards
zEnterhacker
« Last Edit: February 14, 2020, 08:52:11 AM by zEnterHacker »
Logged