I set up a new secondary ISC DHCP server yesterday, as an interim solution while I get round to fixing a dead server. The easiest short term fix was to spin up a VM and install DHCP there. As I think I documented previously, I am running the ISC DHCP server as a primary/secondary pair and balancing the pools across the two of them.

Today at lunchtime I brought up a VPN to my lab and logged in to the VM to check that the new DHCP server was behaving properly, as I hadn’t had a chance to thoroughly test it last night. The logs looked fine, then I took a peak at the /var/lib/dhcp/dhcpd.leases file. Most of my DHCP leases are statically defined, so I was curious to see what if anything was being allocated an address from the dynamic DHCP pool. I found an entry that looked a little odd to say the least:

lease 192.168.8.49 {
  starts 5 2014/10/03 16:31:57;
  ends 5 2014/10/03 17:31:57;
  tstp 5 2014/10/03 16:15:35;
  tsfp 6 2014/10/04 17:01:57;
  atsfp 6 2014/10/04 17:01:57;
  binding state active;
  next binding state expired;
  hardware ethernet 55:4e:20:00:00:00;
  uid "sid5d9fbede82778\000\000\000\000\000\000";
}

The MAC address certainly is unusual. Starting with ‘55’ is an oddity, and ending in all zeroes is a little off the wall too.

Tracking Down 55:4e:20

OUI Check

I figured I might get a clue if I knew what kind of device this was. So I engaged my usual quick and dirty Google search for ““OUI 55:4e:20”, which came up blank. Further digging confirmed my suspicion that this isn’t a regular MAC address. However, doing more web searches didn’t show anything up either; usually somebody has documented an oddity like that. And that’s why we’re here, because I now know what it is and I want to make sure the next curious person gets a useful hit in the search engines!

Switch Check

Since I’m already using SSH to view the server I took a moment to check the MAC address table on my core switch. Sadly no joy – there was no entry for the MAC in question, so the idea of locating where this address was sourced from in my network was also a failure.

DNS Check

In a moment of genius (well, nerdiness and tinkering) when I set up my DNS servers, I also configured them to support Dynamic DNS (DDNS). That means that usually when a device is allocated an IP address, the DNS server is updated with the name of the host using that IP. Let’s try a reverse lookup then:

john@nettools:~$ nslookup 192.168.8.47
Server:     127.0.0.1
Address:    127.0.0.1#53

47.8.168.192.in-addr.arpa   name = macbookpro.home.

Well now isn’t that interesting? That’s the hostname for the (duh) MacBook Pro I’m using to connect to my home network, but I don’t have the 55:4e:20 MAC on any physical or virtual interface. If I check the ARP entry for 192.168.8.47 I get a different MAC address:

john@nettools:~$ arp 192.168.8.47
Address          HWtype  HWaddress          Flags Mask Iface
macbookpro.home  ether   00:0c:39:09:11:3c  C          eth0

So what’s going on?

Junos Pulse Secure Access Service

I run a Juniper Pulse Secure Access server at home (though as @ipv6freely was keen to point out, it’s not Juniper any more). Either way, I run it because it’s a very capable SSL VPN server and it’s free for 2 users which is more than enough for me to use in my lab. I connected using the Junos Pulse client as usual, and my computer is assigned an IP address by DHCP, in accordance with the Resource Policy defined in the Connection Profiles for VPN Tunnels:

It turns out that the Juniper SA device sends a DHCP request sourced from this bogus MAC address, and with that MAC address embedded in the request also:

13:52:10.355285 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 580)
    sa-internal.home.bootps > dns3.home.bootps: [udp sum ok] BOOTP/DHCP,
>>  Request from 55:4e:20:00:00:00 (oui Unknown), length 552, xid 0x33c2dc7f, Flags [none] (0x0080)
          Gateway-IP sa-internal.home
>>        Client-Ethernet-Address 55:4e:20:00:00:00 (oui Unknown)
          Vendor-rfc1048 Extensions
            DHCP-Message Option 53, length 1: Request
            Server-ID Option 54, length 4: dns1.home
            Requested-IP Option 50, length 4: 192.168.8.49
            Client-ID Option 61, length 64: hardware-type 115
            Hostname Option 12, length 14: "macbookpro"
            Vendor-Class Option 60, length 8: "JNPR.IVE"
            END Option 255, length 0

“Oui Unknown,” indeed. My (untested) guess is that if a second user connected to the SA, the MAC address would increment by one so that each user has a unique MAC address. Why not use the MAC address matching the one I saw in the ARP table? Because all the tunnel endpoints will be seen on my LAN as having come from the SA’s internal interface MAC. I can confirm that with a quick check of the ARP table:

john@nettools:/home/john# arp -a | grep 00:0c:39:09:11:3c
macbookair.home (192.168.8.49) at 00:0c:39:09:11:3c [ether] on eth0
macbookpro.home (192.168.8.47) at 00:0c:39:09:11:3c [ether] on eth0
sa-internal.home (192.168.8.115) at 00:0c:39:09:11:3c [ether] on eth0

In this example, macbookair and macbookpro are both VPN clients, and sa-internal is the internal interface for the Juniper Secure Access server. Using the same client MAC address in multiple DHCP requests would not work terribly well, would it?

55:4e:20 – Solved

And that’s it. Simple enough, but confusing if you don’t know that the Juniper SA is using 55:4e:20 as a range of special MAC addresses. If you found this article from a search engine, I hope it answers the same mystery for you!