pfSense

TL;DR 54.231.0.0/16

For those of us with limited upload bandwidth, just plugging an iPhone in for a charge while on home wifi can bring our connection to its knees. As convenient as automatic online backups are, they tend to monopolize all the available bandwidth, and saturating your upload means crippling the download as well (it has to do with buffer bloat, delayed ACKs, and other stuff).

iCloudThrottle

Through some Google-fu I found (one of) the subnet(s) used by iCloud, so that I can easily throttle the upload traffic without imposing a limit on all the upload coming from iOS devices. The subnet is 54.231.0.0/16.

Thanks to my pfSense router, I put together a nifty set of rules that throttles uploads to that subnet from 8 am to midnight, limiting it to 50% of my available bandwidth. During the night, it is unlimited.

Just a quick overview of what’s needed to do that on pfSense (not a full tutorial, sorry):

A schedule that defines the times you want the limit to be enabled
Trafic shaping with a dedicated upload queue with a fixed maximum rate, in addidition the default ones
A floating rule of type Pass, applied on both WAN and LAN, TCP protocol, destination 54.231.0.0/16, active during the day, sent to the queue you created earlier w/ the limit enabled.

Actually I have 2 schedules, one for the day and the other for the night, an additional queue for unthrottled iCloud backups and an additional floating rule that is identical to the one above apart from the fact that it is enabled during the night and sends traffic to the unthrottled queue. This allows me to have nice graphs that show only iCloud traffic. Definitely not necessary, but cool.

kernel: arp: x.x.x.x moved from xx:xx:xx:xx:xx:xx to xx:xx:xx:xx:xx:xx on em0

Ever since adding a pfSense router and a FreeNAS box to my network, I noticed quite a few ARP moved messages in my system logs, and I finally found out what causes them.

TL;DR: Nothing to worry about.

Long(ish) version

First a little background. ARP messages are excahanged in ethernet networks (even wireless ones) in order to keep track to which physical (MAC) address each IP belongs to, so especially if you have static IP addresses or static leases in your DHCP server, you shouldn’t be seeing messages like these, which indicate that a given address is now assigned to a different device, hence the change of the MAC address.

I had noticed a couple interesting things about these MAC addresses: they all belong to Apple devices (you can check by entering the first three 2-character blocks in a lookup service), and one of tham always belonged to a Mac. The other one belonged to an AirPort base station (either an Extreme or an Express), which initially made me worry that somehow my Wi-Fi network was breached and somebody was connecting to it and stealing an IP. Actually it didn’t make much sense, unless the AirPort itself was hacked and used as a sort of relay.

After some googling, I came to this post on the FreeNAS forums where they explained that this behavior is due to a feature of AirPort base stations called sleep proxy.

Basically, when a Mac goes to sleep, its Bonjour-advertiesd services would disappear, making it no longer visibile on the network. AirPort base stations understand Bonjour, and they get notified when a Mac goes to sleep, so they start broadcasting the Mac’s services (file sharing, screen sharing, SSH, etc.) and “grab” its IP. This way, when somebody tries to access one of these services, either because they already knew the sleeping Mac’s IP or because they discovered it through Bonjour, the AirPort wakes the Mac by some kind of WOL technology, maybe a simple magic packet. When the Mac comes out from sleep, it takes its IP back, thus generating a second, opposite entry in pfSense’s/FreeBSD’s system log.