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?
I think the solution is that it will not work on a CPPM management network.
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?
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.
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.
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.
Thank you, that is interesting and useful
ip directed-broadcast -apparently- allows wol across vlans on the HP switches.
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.
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 :)
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.
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)
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.
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.
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.
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...
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)
Configure WoL in your computer's BIOS.
(Window) Enable Allow this device to wake the computer under the Ethernet Connection Properties, Power Management tab.
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.
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-line00077 ports: port 16 is now off-line00435 ports: port 16 is Blocked by AAA00435 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-broadcastip routingVLAN 1 ip address 10.0.1.1/24VLAN 50 ip address 10.0.50.1/24VLAN 100 ip address 10.0.100.1/24interface 48 tagged vlan 50,100
## Access Switch ##
assuming NAC is already working
interface 1/48 tagged vlan 50,100aaa port-access 1/1 controlled-direction inspanning-tree 1/1 admin-edge-port
I hope this helps!
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.
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.
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....
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.