Security

last person joined: 4 hours ago 

Enterprise security using ClearPass Policy Management, ClearPass Security Exchange, IntroSpect, VIA, 360 Security Exchange, Extensions and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Magic Packets/WOL

Jump to Best Answer
This thread has been viewed 23 times
  • 1.  Magic Packets/WOL

    Posted May 21, 2018 03:46 AM

    Hello!

     

    Anyone got any experience with WOL/Magic Packets on a clearpass managed network.

     

    We find it useful to wake up the computers for updates etc.

     

    Anyone got it to work well with clearpass or any alternate ideas?



  • 2.  RE: Magic Packets/WOL

    Posted Jun 12, 2018 07:12 AM

    I think the solution is that it will not work on a CPPM management network.



  • 3.  RE: Magic Packets/WOL

    Posted Jun 12, 2018 02:04 PM

    As long the port is open and you can send WOL-packets I don't really see the issue. How do you define a CPPM management network? Do you mean 802.1X?



  • 4.  RE: Magic Packets/WOL

    Posted Jun 12, 2018 04:53 PM

    Hi,

     

    If you are using a HPE Aruba switch you can use a feature called mac-pin and controlled-direction in so that even if the ports de-auths (PC in standby might) traffic from the server sending the WoL packet will be received by the PC and WoL should work.

     

    Contact me if you need more info.

     



  • 5.  RE: Magic Packets/WOL

    Posted Jun 13, 2018 08:20 AM

    Sounds right!

     

    The aruba guys were onsite yesterday and passed on the mac-pin technote.

     

    I was using it for legacy purposes, but didn't think about using it for another purpose.

     

    The downer is that only a few of our switches support 16.05 firmware, the majority are not supported anymore.

     

    thanks



  • 6.  RE: Magic Packets/WOL

    Posted Jul 10, 2018 04:38 AM

    If you don't have the MAC pinning feature, many switches (and I believe the ArubaOS switches do that as well), do authentication on inbound packets (that behavior may be configurable). If authentication/port authorization is dropped, they will fall back into the default port VLAN (as in the VLAN you configured on the interface).

     

    You can leverage this behavior by sending the Wake-on-Lan packets via a directed broadcast into the VLAN that is your default VLAN. The client will receive the wake-up packet, Power on, then on the first packet sent the authentication will trigger and the client will end up in the production VLAN/role.



  • 7.  RE: Magic Packets/WOL
    Best Answer

    Posted Jul 10, 2018 04:49 AM

    Thank you, that is interesting and useful

     

    ip directed-broadcast -apparently- allows wol across vlans on the HP switches.

     

    and

     

    aaa port-access <port-list> controlled-direction <both|in>

    both (default): Incoming and outgoing traffic is blocked on an 802.1X-aware port before authentication occurs.

    in: Incoming traffic is blocked on an 802.1X-aware port before authentication occurs. Outgoing traffic with unknown destination addresses is flooded on unauthenticated 802.1X-aware ports.

     

    The aaa port-access controlled-direction in command allows Wake-on-LAN traffic to be transmitted on an 802.1X-aware egress port that has not yet transitioned to the 802.1X authenticated state; the controlled-direction both setting prevents Wake-on-LAN traffic to be transmitted on an 802.1X-aware egress port until authentication occurs.

     

    something for me to try out :)

     

     



  • 8.  RE: Magic Packets/WOL

    Posted Jul 10, 2018 05:02 AM

    I test this for a customer a couple off weeks ago.

     

    aaa port-access ethernet 1/1-1/48 controlled-direction in

     

    this works fine, but be sure that the default vlan on the interfaces is that vlan thats been used for WOL.



  • 9.  RE: Magic Packets/WOL

    Posted Jul 10, 2018 11:00 AM

    Yes

    It does work. Just tried it on a switch.

    (but only on some computers, but there is a minefield of nic drivers, windows 10 settings and power options to enable on all of them, but that is another story)

     



  • 10.  RE: Magic Packets/WOL

    Posted Jul 10, 2018 04:02 PM

    Hi all,

     

    One thing to look at. 

     

    I have had devices that want to save energy by putting the NIC on 10FD in the WoL mode. Please change the setting to the value the device has when powered on (100-FD in most cases). Otherwise it could happen that when the device powers down it will change the port speed and the switch will have a port down-port up and this can impact the authentication of the port. And thus resulting in a re-auth of the port, which you don't want.

     

    Hope it helps.

     



  • 11.  RE: Magic Packets/WOL

    Posted Jul 11, 2018 03:04 AM

    Yes, Frank, that helped. Lots of great advice on this thread

     

    I had seen that setting in some of the nic properties, but I never thought to change it.

     

    It indeed enabled some of the computers to work.  Probably the other computers need a driver update to access the setting.

     

    We have so many different models here that is it going to be a long trip.

     

    This advice isn't generally around the internet.

    Thanks

    :)



  • 12.  RE: Magic Packets/WOL

    Posted Jul 11, 2018 12:21 PM
    Hi

    ip directed-broadcast -apparently- allows wol across vlans on the HP switches.

    Yes, but it also opens the door for abuse. If not protected per vlan or acl, smurf attacks among other things are possible.

    https://www.juniper.net/documentation/en_US/junos/topics/concept/ip-directed-broadcast-ex-series.html

    Hope it helps.



  • 13.  RE: Magic Packets/WOL

    Posted Jul 16, 2018 08:55 AM

    Cheers Frank

     

    luckily, I don't need that command.  Works without it..  As least if you have a realtek nic, the intel ones still don't like it so far.



  • 14.  RE: Magic Packets/WOL

    Posted Jul 16, 2018 05:50 PM
    Hi

    On HPE Aruba AFAIK ip directed-broadcast is on by default on some firmware version. So maybe that’s why you didn’t need to turn it on. It’s on by default.



  • 15.  RE: Magic Packets/WOL

    Posted Oct 14, 2018 05:35 AM

    Interested in this as we are trying to use Clearpass and Controller to use downloadable user roles and create GRE tunnels to isolate traffic from other clients on switch. With dot1x and MAC auth however the way I understand dot1x nothing gets through until the port is authenticated, so theoretically even if the port default VLAN is the same as the wol server the port will block the traffic. I will test the previous suggestions but as a fall back maybe if MAC auth sets the VLAN then traffic can get through? Has anybody used DUR and WoL and PXE on the ports, yep hoping MAC auth will make PXE work also...

     

    Cheers



  • 16.  RE: Magic Packets/WOL

    Posted Oct 14, 2018 06:19 AM
    Hi

    Please look at port access controlled direction in and Mac pinning on ArubaOS-SW models

    Cheers


  • 17.  RE: Magic Packets/WOL

    Posted Jan 31, 2019 02:31 PM

    When I first began working on WoL, I read this post thread, much like many will read as time goes on, and yet I still could not get WoL to work, but eventually I did.

     

    I will attempt to summarized all that has been said, and needs and some added things done to get WoL working.

    Some Requirements (just stating the obvious)

    1. Configure WoL in your computer's BIOS.

    2. (Window) Enable Allow this device to wake the computer under the Ethernet Connection Properties, Power Management tab.

    3. Aruba AOS aka HPE Proview/Provision switching running version 16.x or newer (I can't confirm WoL on older versions)

    On the switch, you will need to configure the port for controlled-direction in

    i.e. aaa port-access 1/1 controlled-direction in

    This allows traffic from the switch to egress the port, so the sleeping computer NIC may process packets.

    IP directed-broadcast is only required on the switch performing Layer-3 routing. For Layer-3 Distribution and Access switches, it will do nothing.

     

    Note: ip directed-broadcast globally activates broadcast forwarding/routing between all VLANs. This feature is notorious for being exploited for LAN DOS attacks, therefore I highly recommend setting the optional access list, to only allow WoL from a trusted source.

    The interface untagged must a VLAN serviced by a routing instance.

     

    For example:

    When a device is authorized, it is put in VLAN 100 services by the core routing device with a SVI of 10.0.100.1.

    SVI- Service Virtual Interface (Fancy talk for a Layer-3 VLAN)

     

    When the device goes to sleep, the port is de-authorized, the Ethernet port is change to the default untagged VLAN 1, serviced by the core routing device with a SVI of 10.0.1.1.

     

    The WoL server is at 10.0.50.100 in VLAN 50 with a SVI of 10.0.50.1.

     

    When the WoL packet is sent from the WoL server to 10.0.1.255, the core SVI 50 will route the packet out to SVI 1, thanks to the ip directed-broadcast command.

     

    Here is the part that is not in the ArubaOS-Switch Guide, if you are running spanning-tree, it takes precidence and will block traffic despite the “controlled-direction in” command.

     

    What I discovered, and shared with support, is for a port to be allowed to forward, when blocked by AAA, the port must be set to STP admin-edge.

    i.e. (config)# spanning-tree 1/1 admin-edge-port

     

    When everything is set correctly, on an unauthenticated port you should see in the log this succession of events:

    00076 ports: port 16 is now on-line
    00077 ports: port 16 is now off-line
    00435 ports: port 16 is Blocked by AAA
    00435 ports: port 16 is Blocked by STP <- STP kicks in after AAA, therefore trumping it.
    00076 ports: port 16 is now on-line
    <- Admin Edge allowing the port to forward

     

    In reality STP admin-edge is a good thing. It allows the port for begin forwarding a few seconds more quickly.

    If you are concerned about STP protection, when STP is detected on a admin-edge port, it will fail back to full STP mode, while connected.

    If a loop is created, one of the ports will begin blocking, protecting the network.

    Note: The need for admin-edge in conjunction with “controlled-direction in”, if STP is enabled, is not in the command reference documentation. The engineer I worked with said he would request documentation update to mention it.

     

    And for the example config:

    ## Core Switch ##

    ip directed-broadcast
    ip routing
    VLAN 1 ip address 10.0.1.1/24
    VLAN 50 ip address 10.0.50.1/24
    VLAN 100 ip address 10.0.100.1/24
    interface 48 tagged vlan 50,100

    ## Access Switch ##

    assuming NAC is already working

    ...

    interface 1/48 tagged vlan 50,100
    aaa port-access 1/1 controlled-direction in
    spanning-tree 1/1 admin-edge-port

     

    I hope this helps!





  • 18.  RE: Magic Packets/WOL

    Posted Jan 31, 2019 02:37 PM

    Hi

     

    Nice summary.

     

    Keep in mind that with NAC you mostlikly have a logoff-time/session-timeout. This will remove the valid authentication from the port. As most WoL NIc don't regulary send out traffic the port will stay unauthenticated and WoL will no longer work until the port is authenticated again.

     

    IP client-tracker might help out.

     

     



  • 19.  RE: Magic Packets/WOL

    Posted Feb 01, 2019 09:38 PM

    Yes, when the PC goes to sleep, the port will deauth when the NIC changes to 10/half, for power saving.  This same event will clear whatever MAC was on the port from the switch.

    The beauty of controlled-direction in is that it allows traffic to egress from the port, i.e. WoL, to the Ethernet card that it can wake the computer, yet ingress traffic, not that there should be any for a in lower power mode. 

    A WoL packet has a destination MAC of FF:FF:FF:FF:FF:FF (broadcast) because the PC trying to woke doesn't have a MAC in the switches forwarding table.  Since a broadcast packet is sent out all ports (in that VLAN) it will also be forwarded out the ports with "controlled-direction in" enable, thus waking the PC it is destine.

     

    As for client-tracking, that will not be of any use, even if it hasn't expired, because there is no MAC in the forwarding table.

     

    Nothing to do with WoL, but when using client-tracking, be sure to also use probe-delay, with NAC, or it tends to confuse Windows PCs when renewing DHCP leases, and can cause BAD-ADDRESS entries in you Windows DHCP server, and duplicate IP messages on PCs.

    In conjunction with NAC this has worked well for me:

    ip client-tracker trusted

    ip client-tracker probe-delay 30

    The probe delay was added in ArubaOS (switching) Version 16.05.0007 so upgrade...

     

    I hope this helps clear some things up.

    Cheers!

     



  • 20.  RE: Magic Packets/WOL

    Posted Feb 02, 2019 01:21 AM
    Hi

    Thanks for the long reply.

    A WoL packet has a destination MAC of FF:FF:FF:FF:FF:FF (broadcast) because the PC trying to woke doesn't have a MAC in the switches forwarding table. Since a broadcast packet is sent out all ports (in that VLAN) it will also be forwarded out the ports with "controlled-direction in" enable, thus waking the PC it is destine.

    This will only work if the port is in the VLAN the WoL packet is send in. In many deployments with NAC the port has a default VLAN and the correct VLAN is assigned by NAC when the PC authenticates. In that case by my understanding controlled-direction in will not work correctly as the port in deauth state is in the default VLAN and not the VLAN the WoL packet is send in.


    As for client-tracking, that will not be of any use, even if it hasn't expired, because there is no MAC in the forwarding table.

    If you change the nic settings of the NIC of the PC to not change the speed settings the port will still be authenticated when the pc goes to sleep because if does not change speeds. Then I might help because the MAC address is still in the forwarding table.

    The probe delay was added in ArubaOS (switching) 17.x so upgrade...

    17.x on which switch? Of do you mean 16.x?


    In many cases WoL is a tricky thing to get working and has many dependency’s: correct vlan on the port, ip client tracker, correct speed settings on the nic, etc.



  • 21.  RE: Magic Packets/WOL

    Posted Feb 02, 2019 02:13 AM

    17.x on which switch? Of do you mean 16.x?


    In many cases WoL is a tricky thing to get working and has many dependency’s: correct vlan on the port, ip client tracker, correct speed settings on the nic, etc.


    I'm sorry for the my gross error in version numbers.  I found the exact version that the delay was added to ArubaOS and updated my post.

     

    I completly agree, things can get especially tricky if you are changing a port VLAN association based on authentication, default untagged port VLAN etc.

    Personally I'm strugling with how KACE does handles WoL.   During testing, the only way to effectivly make WoL work was to set the untagged VLAN to the same as the workstation VLAN.  I'm not super keen on this, from a security standpoint....

     



  • 22.  RE: Magic Packets/WOL

    Posted Feb 02, 2019 03:57 AM
    Hi

    No gross error in my opinion. We are all humans on this community. So be proud to be a human!

    Together we reach higher goals!

    Thanks for sharing.



  • 23.  RE: Magic Packets/WOL

    Posted Jun 08, 2021 09:24 AM
    Hi,

    I am having issue with WoL with clearpass/aruba OS

    When the devices is in sleep mode the interface on the switch goes to a 'down' state. Unsure what I am missing here to allow the device to be reachable ? Is this a switch issue or a client issue ?

    Many Thanks in advance

    David

    ------------------------------
    David Hurley
    ------------------------------