• July 15, 2020, 09:03:53 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 875 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

FurryNutz

  • Poweruser
  •   ▲
    ▲ ▲
  • *****
  • Posts: 48970
  • D-Link Global Forum Moderator
    • Router Troubleshooting
Re: WakeOnLan (WOL) over L2TP tunnel from Windows 10 - Edited !!
« Reply #1 on: February 24, 2020, 12:58:45 PM »

I recommend that you phone contact your regional D-Link support office and ask for help and information regarding this.
Link> Tech Support Contact Information
We find that phone contact has better immediate results over using email.
Let us know how it goes please.
Logged
"Nothing Funny about It...." We are not here to Impress anyone! You have a be a COMPETENT user first to under stand COMPETENT help!