First things first: don't try this at home!
The context here is an enterprise network, making use of Cisco equipment, where 802.1x has been deployed for wired endpoint connections. Here comes the last ingredient: you would like to use "Wake-on-Lan" (WoL) to remotely turn on PCs at your will.
WoL magic packets are specially crafted frames that contain the physical address (mac) of the host to be awakened. Since it is connected but powered off, this host does not advertise itself and its mac is not visible to the directly connected switch. For this reason, the magic packet needs to be broadcasted over the destination L2 vlan.
This is trivial if you can send the WoL packet from the same vlan, but a little more care must be taken if an L3 network is between you and the target host. In this case the magic packet takes usually the form of a UDP datagram, with destination port 9. When the packet reaches the last router, and should be broadcasted over the target vlan, the router will typically by default block this kind of traffic, which is potentially dangerous: otherwise it would be too easy to remotely flood target vlans.
On Cisco routers you can overcome the protection by issuing the ip directed-broadcast <acl_num>
on the relevant subinterface or VlanN configuration. For example:
interface GigabitEthernet0/0/0.709
description Vlan 709
encapsulation dot1Q 709
ip address 172.28.4.254 255.255.255.0
ip directed-broadcast 11
Only the ip addresses and subnets permitted in access-list 11 will be allowed to send WoL magic packets to vlan 709.
Following the example, with this acl you could send WoL packets from 192.168.1.10, but not from 10.99.2.2:
access-list 11 permit 10.99.1.1
access-list 11 permit 192.168.1.0 0.0.0.255
If the target (sleeping) host was connected to a switchport in mode access vlan 709, we would be ready to start using WoL.
Add 802.1x to the mix. Switch ports now require authentication, and only then dynamically assign a vlan to the host, based on authorization information returned by a radius server. When the host is powered off, the port becomes unauthenticated, and leaves no trace of the previously assigned vlan.
Fortunately, we are not left outside alone, and Cisco documents what we need even in this case:
IEEE 802.1X Wake on LAN Support (for 3850 switches)
IEEE 802.1X Wake on LAN Support
The important bit is adding authentication control-direction in to the switchport configuration, because this:
Sets the port as unidirectional. The port can send packets to the host but cannot receive packets from the host.
In our case port configuration was looking like this:
interface GigabitEthernet1/0/xx
description Auth_802.1x
switchport mode access
switchport voice vlan 50
srr-queue bandwidth share 10 10 60 20
queue-set 2
priority-queue out
authentication control-direction in
authentication event no-response action authorize vlan 703
authentication port-control auto
authentication periodic
authentication timer reauthenticate 43200
mab
mls qos trust device cisco-phone
mls qos trust cos
dot1x pae authenticator
dot1x timeout quiet-period 3
dot1x timeout tx-period 1
dot1x max-req 1
dot1x max-reauth-req 1
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
end
You can notice that Cisco IP Phones use voice vlan 50, and that there is a "guest" vlan (703) in case 802.1x authentication fails.
So, over which vlan id can we reach the target host, when it is powered off, provided we do everything else correctly? The answer, which I could not find explicitly stated in Cisco documentation, is... vlan 1.
Thus we need to have an addressable vlan 1, with a subnet known and routed by the rest of the L3 network.
Back on the router:
interface GigabitEthernet0/0/0.1
description VLAN 1 WOL_support
encapsulation dot1Q 1 native
ip address 10.25.19.5 255.255.255.252
ip directed-broadcast 11
Ensure vlan 1 is active on switches and allowed within interconnection trunks.
Finally we can send the WoL magic packet, aimed at our target MAC address.
Note that the ip destination ("Host Name" in the form above) is set to the broadcast address of the subnet associated with vlan1.
Before sending the magic packet, the switch port will report no clue of the target host (the port is connected and showing a mac address only because an IP Phone is present, in voice vlan 50):
switch#show mac address-table | incl 1/0/32
50 0026.0b5c.6661 STATIC Gi1/0/32
switch#show spanning-tree int Gi1/0/32
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- -----------
VLAN0050 Desg FWD 19 128.32 P2p Edge
switch#show int status | incl 1/0/32
Gi1/0/32 Auth_802.1x connected 1 a-full a-100 10/100/1000BaseTX
Shortly after sending the magic packet, the situation starts to change, with the target host mac showing up in vlan 703 (guest), because it is booting but not ready to perform 802.1x yet.
switch#show mac address-table | incl 1/0/32
50 0026.0b5c.6661 STATIC Gi1/0/32
703 1458.d005.1058 DYNAMIC Gi1/0/32
One minute later, the target host is able to authenticate successfully, and is placed in the correct 802.1x vlan (in this example, 709).
switch#show mac address-table | incl 1/0/32
50 0026.0b5c.6661 STATIC Gi1/0/32
709 1458.d005.1058 STATIC Gi1/0/32
Hooray!
Share on Twitter Share on Facebook
Comments
blog 4 years, 8 months ago
I think this is among the most vital information for me.
Link | ReplyAnd i am glad reading your article. But should remark on few general things, The web site style is great,
the articles is really nice : D. Good job, cheers
พนันออนไลน์ 3 years, 9 months ago
Wow, that's what I was exploring for, what a material! existing here at this blog, thanks admin of this web
Link | Replypage.
blog3004 4 years, 8 months ago
Appreciating the persistence you put into your website and
Link | Replydetailed information you present. It's great to come across a blog every once in a while that
isn't the same unwanted rehashed material. Excellent read!
I've saved your site and I'm including your RSS feeds to my Google account.
New Comment