Wake-up On LAN (WOL)

When your infrastructure contains mostly thin clients, in many different locations, you might very well benefit from a working Wake-On-LAN (WOL) solution for upgrading thin clients during out-of-office hours on remote locations.

The problem with a central WOL deployment is the network security part. Why? WOL mostly uses broadcast frames to send the Magic Packet to the MAC-Address of the this client. Broadcasts are blocked by the first router in the network (usually the default gateway of the subnet the WOL server is connected to). Every routing hop in a corporate network specifies a separate broadcast-domain. Broadcasts are limited to these subnets between 2 routing hops.

How to pass this first boundary?

On Cisco routers or layer-3 (and up) switches you can use the ‘ip helper-address ip-address’ command to specify an ip address to forward broadcast frames transformed to unicasts.

The ‘ip helper-address’ command is mostly used to enable local subnets to receive DHCP-leases from a remote DHCP server. The picture below shows this setup:


The configuration on the Cisco device functioning as the default-gateway is limited to:

> interface fastethernet0/0
> ip helper-address 10.0.0.10

In this scenario it’s the client who’s sending the broadcast onto the local subnet, which is picked up by the Cisco router. The Cisco router transforms the broadcast into an unicast and sends it to de DHCP-server.

By default a Cisco router will forward the following eight broadcasts to the addresses specified by the ‘ip helper-address’ command:

1) Time Protocol (port 37)
2) TACACS (port 47)
3) DNS (port 53)
4) BOOTP Client (port 67)
5) BOOTP Server (port 68)
6) TFTP (port 69)
7) NetBios (port 137)
8) NetBios Datagram (port 138)

Now let’s see what is needed to get WOL working from the Datacenter to the remote locations is the scenario presented below:


Like we’ve seen with the DHCP setup. In order to forward a broadcast frame to another ip address we’ll have to use to ‘ip helper-address’ on the local subnet, but a WOL frame doesn’t come with an ip-address. It’s a broadcast frame which contains the MAC address of the system we want to wake-up. This is the reason why we’ll have to specify the broadcast address of the remote subnet as the ‘ip helper-address’. This way, the frame will be forwarded to the broadcast address of the local subnet and all thin clients will receive the frame, but only the system with the MAC-address specified in the payload will be woken-up.
So in order to forward the WOL frames to the two remote subnet’s we’ll use the following config:

> configure terminal
> interface fastethernet0/0
> ip helper-address 10.1.1.255
> ip helper-address 10.2.2.255

But there’s one more thing that needs to be done on the central side of the corporate network. Remember that there are only eight types of broadcasts that are forwarded by default? Well, WOL isn’t (in most cases) one of them.

We’ll have to specify to UDP-port that the WOL packet will be transmitted to. In some cases this port is 0 (discard) or 7 (echo), but it could be any port depending on the type of software used. For example, the utility ‘wol.exe’ uses UDP port 12287. In order to find out which port is being used you can use Wireshark to sniff some WOL packets and check the UDP Layer header information:


Note: For this blog I generated a WOL packet to a non-existing MAC-Address (Green Circle)

Now that we know which port (Red Circle) the WOL packets are transmitted to, we can use the ‘ip forward-protocol’ global config command to enable the forwarding of broadcast frames on that specified port.

> configure terminal
> ip forward-protocol udp 12287

The central part of the configuration is done, all WOL packets on port 12287 are forwarded to ip-addresses 10.1.1.255 and 10.2.2.255. Still, we’ll have to make sure that on the remote location the forwarded broadcasts are transmitted out onto the local subnet where the thin clients are located. Because the x.x.x.255 addresses are broadcast addresses this will not work by default. ‘ip directed-broadcasts’ have to be enabled on the local interface in order to transmit the WOL frames as broadcasts onto the local subnet. To secure this behavior we will add an access-list to the command specifying which systems are allowed to send directed broadcasts.

On the remote locations we’ll add the following configuration:

> configure terminal
> access-list 101 permit udp host 10.0.0.10 any eq 12287
> interface fastethernet0/0
> ip directed-broadcast 101

That’s it! Thin clients on the remote locations can now be woken-up with WOL frames originating from the central WOL server.

x64 Cisco IPSec VPN Client

Finally, Cisco has released a IPSec VPN client for the x64 Windows platform. Check it out:
release notes

Fast Pinger

Let’s talk about one of my favorite tools: Fping.exe

Fping mostly works like the well known ping command that’s available in every windows/unix/linux OS, but gives you some more options that make it a tool to use when testing failover technologies in your network.

Let’s look at the additional options from the fping.exe command that aren’t available from the ping.exe command :

-S : size sweep. Ping with size1, size1 + 1, ..., size 2 datalength

One might wonder when this option is useful. Have you ever tried to determine the MTU of a particular network? Testing it with best guesses using the “-f don’t fragment flag” option combined with the “-l ” option in the ping command? Here’s how to determine the MTU using fping.exe in a single command:

Fping 10.0.0.1 -S1400/1500 –t1 –f


The output speaks for itself! Another option (I already used in the previous example) is:

-t : time between 2 pings in ms up to 1000000

The “-t” options let’s you specify the time between 2 pings. This is particular useful for speeding up the whole process in combination with the “-c Continues Ping” option. To demonstrate this I’ll use a third cool option, which is:

-D : print datestamp and timestamp with each reply

Also available with only the time information:

-T : print timestamp with each reply

Using the ”–D” of “-T” options I can show you what the speed difference is when using the “-t” option.

First off, let’s ping a host 5 times without the “-t” option:

Fping 10.0.0.1 –n5 –D


As you can see, default behavior is sending 1 ping every second (look at the timestamps). Now, that’s not really fast, is it? Now let’s ping a host 200 times with the “-t” option:

Fping 10.0.0.1 -n200 –t1 –D


In the output you can find that it’s possible to send approximately 150 (reply 7 – reply 156 are all within 1 seconds (21:25:48)) ICMP packets per second using the “-t” option. So when checking failover mechanisms, this ping tool will most definitely show more detail of the outage than the regular ping tool.

A relative new option is:

-j : print jitter with each reply (only when pinging one host)

This option also shows the jitter on the network:


Being able to test for excessive jitter can help a lot when troubleshooting voice-over-ip networks.

The last option I would like to bring to your attention is de “-L ” option:

-L : logging to a text file

With this option you’re able to also log the output to a textfile. The ‘also’ means that with the normal ping command, as with every command utility, you’re able to redirect the output to file instead of the display, but not to show the output on screen and also log it to file.

You can download this utility at kwakkelflap.com. Check it out!

Sniffing dot1Q tags with wireshark

Ok, so here's the issue. When testing some QoS settings on a customers network I wanted to verify layer-2 QoS (CoS) using Wireshark. I've done so many times, but recently I got a new laptop (HP Elitebook 8530P) and I noticed that no matter what I configured in the monitor session, no dot1q tag would appear in Wireshark.

Today I created a small testlab which you can see below.


I configured the following SPAN session:

monitor session 1 source interface Fa0/23
monitor session 1 destination interface Fa0/24 encapsulation dot1q

I sniffed some ICMP packets originating from FW1 towards FW2, which gave me the following Wireshark output:


Clearly no dot1Q tags present in the captured data.....

After some searches on the web I found out that newer drivers strip off tags like dot1Q by default and therefore are not available to upper layers in the OSI-model.

In my case it concerns an Intel 82567LM Gigabit Adapter which, luckily for me, has the possibility to turn off this 'strip off' feature by setting the following registry key: MonitorModeEnabled, value 1, type DWORD, at the following location:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\00xx


The '0007' part of the registry location may differ from laptop to laptop. You can check by looking at the DriverDesc string in each folder.

After a quick reboot I did the same test as earlier with the output below:


YES! It's working again like it should. The yellow circle shows the CoS value and the blue circle shows the VLAN-id. Time for some QoS testing next week....

Welcome!

Welcome to this new blog! Obviously there's not much to read.....yet! Stay tuned and I'll try to write articles on a regular basis regarding networking and network security.