Wake on LAN - offline node - dropped from ARP

[NdridCold]

Was wondering if I have 2 PC's on the same subnet/VLAN (may be on same switch, maybe not, may not matter) If PC 1 sends a WOL packet to PC 2 which has been in a powered down state for longer than the switch keeps ARP entries alive would the WOL packet get dropped? I'm pretty sure it will, but I am also thinking about NIC's that are maybe capable of somehow keeping its ARP entries alive while in a powered down state?? Is there such a NIC that can do this? If so, how?

 

[bill001g]

Wake on lan does not use IP or ARP. It is a special broadcast packet that contains the mac address inside the payload part of the packet. Since it is a broadcast packet it is sent to every port. The switch does not have to keep track of anything it just sends it to everyone. The end device when running WOL is actually receiving and processing any packet that is sent if it finds one with its mac address inside it causes the machine to activate.

 

[NdridCold]

Thank you for the response. And your're right - if you are speaking in terms of a subnet-directed transmission method. What if the method of transmission is unicast? Most enterprise network environments will opt for the more secure unicast method.

 

[bill001g]

This gets a little messy. This is similar to what happens if you ping the broadcast address of a subnet from a remote location. This is disabled in most devices due to attacks.

What it does is send the packet over the network using normal routing until it gets to the end router that has a interface on the subnet. The subnet will always be in the routing table unless the interface is down..and that assumes you are using a routing protocol that can detect it. The edge router is configured to accept this special packet and converts it back into a broadcast packet. In effect the edge router becomes the device that initiates the actual WOL packet.

This only works on routers that have support for this feature.

 

[NdridCold]

That makes sense. But lets make this less complicated and remove the router from the picture. Say we have PC1 and PC 2 on the same Subnet/VLAN. This would essentially keep traffic at the switch level. Using the unicast method, (1) would an ARP entry be placed in the switch ARP table? (2) If # 1 is true, what would be the result if PC1 sends a WOL packet to PC2 in a powered down state for longer than the TTL's of the switches ARP entries? Would the switch drop the packet since the entry expired for PC2? Do some switches have the broadcast conversion feature that you mentioned for routers built in?

 

[bill001g]

Never used it that way. Normally you use unicast wol when you must cross subnets and use broadcast within the same subnet. What you are wanting to do is use a tool that was designed to solve the cross subnet issue on the same subnet. The reason the unicast works is because the router has special support to make it work. If you were to run it without the router you will likely have arp timeout issues. The arp timeouts would be in the PC that is actually sending the WOL packets. The switch only uses mac addresses.

If the PC sending the WOL would timeout the ARP or say never have it would always send a ARP and then send the unicast packet. Since it never gets a response to the ARP it would never send the packet. Not sure how you fix this its all in the PC doing the WOL. It would be best if the PC figures out it is the same subnet and switches back to broadcast WOL packets.

 

[NdridCold]

I had to read your last paragraph about 10 times before I understood what you were saying I think you were saying this is why unicast would not work confined to the same subnet. I am with you now. You have been most helpful. Thanks so much for your time!

 

[NdridCold]

One more question. If you were to implement unicast WOL within a single subnet, why would the ARP depend on the PC's and not the switch? The switch has ARP tables as well. I know either way it would fail whether its the switch that never receives the ARP request back or the PC never receives it, so the WOL packet never gets sent or its droped by the switch. But since both have ARP tables, who or what would determine which one controls the behavior of WOL?

 

[NdridCold]

Also, are the security risk the same such as smurf attacks and things like that when you are doing subnet diretcted broadcast within a single subnet? If you have an app on a PC that is performing WoL I suppose it would be possible for an attacker to gain access to the newtork stack and kick off some sort of DDoS but would you say this would be considered a low vulnerability as opposed risk with a subnet directed across routers implementation?

 

[bill001g]

The switch in general does not have a ARP table. The only purpose of a ARP is to translate a IP to a MAC. All traffic is actually sent to mac addresses. Any ip that is not in the subnet is sent to the mac of the gateway..ie the router.

A switch only knows mac addresses it keep track of which mac address it saw on what port. It looks at every packet and keep track of which port the source mac in a packet came in on. Then it can send and traffic with a destination mac to that port. Of course if it does not have a mac address it just send the traffic to all ports. On a unmanaged switch this is all there is. There is no ip on the switch and it know nothing about ip. This is why you can put a switch on any network and it will work with no configuration and no knowledge about subnet masks.

I have only done this on commercial cisco equipment so it may work differently on other platforms. To make this work with unicast you need to enable a feature called directed broadcast. This lets you send traffic to the broadcast address of a subnet. This used to be on by default but as you mention smurf attacks got this to be changed. Cisco lets you specify the IP addresses of who is allowed to send these. Obviously since it is a one way send someone that knew the allowed ip could spoof the IP but at least you can try to limit it.

How exactly this works I never did spend the time to figure out. A WOL packet does not have a IP header in it. pretty much it is a special string of data that says it is WOL and has a mac of the machine to wake. The router somehow stripping the IP headers off. Since the PC you are waking you don't really know its ip since it could be assigned a anything by the DHCP servers IP does not mean much at this early stage. Since all you really know is what subnet the pc is in you would send to the broadcast for the subnet.

I can see how the router can intercept this if you are coming in from a different subnet. It knows for example the packet came in in g0/0 and is destined for say interface g0/1 since that is where the subnet is. It can then see it is the broadcast address for that subnet and convert the packet. Now if you were on the same subnet as the machine you wanted to target I can't see why the PC would ever send the traffic to the router. It will either figure out that it is the broadcast address and just send it...but it would still have the IP headers I would think.

I have only used unicast from outside the subnet and broadcast from inside. The part I am still unclear about is if it matters at all what the ARP entries are. You run WOL on a mac address not on a IP. You have to assume that the WOL PC might get a different IP so if their is a ARP entry for one ip and it got a different IP the second time you would just have 2 IP mapped to the same MAC for a period of time.

Generally I have not used this a lot lately. They powers that be have decided that power savings were secondary and all servers needed to be able to be constantly monitored even if it was a backup server. When you run WOL you can never really be sure, you can remove the hard drives and it will still keep the ethernet port lit but it will never boot.

 

[ShadeTreeTech]

I think you may be confusing ARP table with the MAC table. Layer 2 devices (switches), do not have an ARP table. Without a Router, the ARP is done by the PC itself (host). The PC will do an ARP request of the switch to identify which port of the switch to send the frame. The ARP table (cache) is on the PC itself in this case. Layer 2 switches don't know and don't care about Layer 3 (IPs).

There are 2 "switch" types will have an ARP cache, neither of them use an ARP for the switch process, AKA layer 2.
1) a managed switch because it has an IP address to allow for remote access, and therefore will have an ARP cache entry for that management access IP, like any other device that has an IP.
2) a layer 3 switch, which is basically a switch and router in 1 device.

 

[NdridCold]

Thanks guys, very helpful. I could have swore that when I was working with the Cisco catalyst L3 switches at a previous job that I ran an arp command and got a MAC to IP inventory? But ShadeTreeTech you're saying that a switch will have an ARP cache/table, but is essentially not used at the L2 level, correct?

Could one of you please elaborate more on my security concern? If you are doing subnet-directed WoL and confine it to a single subnet would this be as big of an attack vector as say implementing cross-subnet directed WoL? In my use case I will have an application on a PC that controls sending of the packets and it will be a subnet-directed transmission method which is only allowed to broadcast on its own subnet.

 

[bill001g]

A L3 switch is technically a router. It only has ARP entries if the switch itself is sending traffic to the end devices. If the traffic is going vlan to vlan then the router part is involved. If the traffic is flowing within a LAN the switch will act layer 2 and only uses mac addresses.

I am now getting very confused on this and may have to take a sniffer and actually look at the packets.

A WOL packet is broadcast packet so I don't see why ARP matters at all. The packet in the payload contains the mac address repeated 16 times or something. So the packet that the device is looking to wake on must be a broadcast packet and contain the device mac address in the payload.

So option 1 we send it to the broadcast mac address with just this data in it with no ip headers or anything else.
Option 2 we use unicast. This means we send it to the broadcast ip of the subnet so 192.168.1.255 for example. There is no arp involved since we know it is the broadcast address the mac will be FFFFFF and so we now have a broadcast mac and a broadcast ip. The WOL client could care less it appears it if find this magic string of mac addresses in the payload it assumes it for him.

Now if you were to use unicast between lans you would send it to the broadcast address of the other lan. So say you were on 192.168.1.x and the WOL machine was someplace on 192.168.2.x. You would send a to 192.168.2.255 containing the mac address of machine to wake in the payload. In this case the sending machine would need a ARP for its gateway. The packet would contain the generating PC mac and the source and the router mac as its destination. Now when the router get it should figure out this is being sent to the broadcast address. So it will replace the source mac with its mac for the its lan on 192.168.2.x and set the mac to FFFFFF. It does not do any ARP at all since in knows the mac is going to be ffffff.

I can't see how we got off on the arp discussion. The PC technically does not have a IP until it is up and running and have validated with the DHCP server that it can still use that IP. Even if we would assume a static IP WOL is not sent to a particular mac address so even if it looked up a pc mac in the ARP table if it would send a packet to that mac the device would ignore it since the WOL must be a broadcast packet which by definition must have FFFFFF for a destination mac address.

Security wise there is no way to prevent someone from sending packets with a broadcast mac that is on the same subnet. That is how everything works. To go between subnets the router must allow data to be sent to the broadcast address. It is the one that will convert it from a IP packet to a actual broadcast with a destination mac of ffffff. As pointed out previously this feature is disabled by default on a lot of equipment due to attacks.

 

[NdridCold]

I would like to see a sniff output from each transmission method myself. Everything I read on subnet directed refer to a cross subnet implementation, so it uses both MAC and IP. Everything I read on unicast uses IP to route to the subnet, and the mac to contruct the WoL packet, but no mention of any broadcast involved.

 

[ShadeTreeTech]

Sorry if this is way late for this discussion, but "bill001g" is correct. The actual WoL frame is a broadcast. You are performing a Unicast IP request to get to the proper subnet, but the encapsulated frame is a broadcast.

There is no "construct" at the end of the path. The WoL frame is constructed at the start, and then wrapped in the packet, with it's IP address to get to the proper subnet. Once it gets to the switch level, the packet has been scraped off the frame, and the WoL broadcast for that subnet is left.

If you enable WoL on the computer, it responds to the call. If WoL isn't enabled, it ignores the broadcast and doesn't respond.

As far as exploits are concerned, I'm not aware of anything at that level. It's a switch to turn on, that's it, there's no "ack", "sync", or any other communication. It's a one way bus to that subnet. I don't mean to make this sound like I'm making light of this, because I'm no expert by any means. If someone kept randomly sending WoL frames to your subnet, it would wake up your machine, but it wouldn't be anymore exposed than it being "On." Once the machine is on, it doesn't attempt to turn on again. I see someone trying to PING ya to death before they use something as obscure as WoL.

As far as your previous statement about a Layer 3 switch, yes you are correct. It absolutely will have an ARP cache in addition to a MAC table. However, it's two devices, which do two different things, wrapped together in the same box, and uses the same CLI or GUI to interact with either component as needed. They still operate separately as far as how they work with the OSI model. Basically instead of having a router sitting on top of a switch and them connected, they are internally connected within the same physical box. They are great because you don't have to login twice, faster communication, some even have auto checks between each side, etc...