Sharing Printers Between OS X Boxes in a Screwed Up Local Network

One of the reasons I bought a Mac for myself and my wife is that I could never get printer sharing working between Linux and Windows. I figured if Marina and I both had Macs then the problem would be solved. Unfortunately, I was wrong. While Apple has mostly embraced Bonjour technology there is still one major area that is left out – Apple's Printer Server (e.g. the open source CUPS) which uses its own multicast based discovery solution. When I hooked my USB printer to my OS X box and turned on printer sharing I couldn't get my wife's Mac to see the printer! The problem turned out to be that both my wife and I's computers have unique IP addresses that we get from our ISP's DHCP server. Unfortunately the ISP's DHCP server gave us addresses in different subnets! CUPS default configuration does not allow printer sharing between machines that are not on the same subnet. The CUPS configuration can be overridden fairly trivially but I don't want to because it would either mean hard coding in my wife's IP address (which changes) or allowing the whole world to print on my printer (which I'd rather not). Thankfully there was a really trivial solution to the problem that was pointed out to me by Stuart Cheshire, the father of Bonjour.

Stuart actually suggested two solutions. I selected his second solution and describe in detail how to implement it below. At the end of this article I explain what his first solution was and why I didn't choose it.

The crux of Stuart's solution is to create a second Ethernet configuration on both my wife and I's machines. This is trivial to set up (once you know how) and from there everything will just 'work', e.g. the printers will just show up.

Instructions for the machine that is hosting the printer:

Step 1 – Go to system preferences (you can get there by clicking on the apple in the upper left hand corner of the screen)

Step 2 – Go to 'Sharing'

Step 3 – Select 'Services'

Step 4 – Select 'Printer Sharing' (depending on how you configured your machine you might have to click on the lock icon at the bottom left hand corner of the dialog box and type in your administrator password before being able to change the Printer Sharing setting)

Step 5 – 'Show All'

Step 6 – 'Network'

Step 7 – 'Show – Network Port Configurations' (this is a choice in the drop down titled 'Show')

Step 8 – Select 'Built-in Ethernet'

Step 9 – Press 'duplicate'

Step 10 – Enter in a title, I choose 'Local Only Ethernet'

Step 11 – Press 'Apply Now'

Step 12 – Select 'Show – 'Local Only Ethernet''

Step 13 – Set 'Configure IPv4' to 'Manually'

Step 14 – Set 'IP Address' to ''

Step 15 – Press 'Apply Now'

The computer hosting the printer is now ready to share that printer with all local machines (including one's your ISP has given the same subnet address to, so beware!).

For each of the machines that you want to be able to use the printer with do the following:

Step 1 – System Preferences

Step 2 – Step 11: Follow the instructions specified above for steps 6-15 with the exception that in step 14 when entering the IP address enter If you are adding multiple machines then each one needs its own IP address, just increment, e.g.,, etc.

Step 12 – 'Show All'

Step 13 – 'Print & Fax'

Step 14 – Press the '+' Button

Step 15 – The printer on the other machine should show up in the list of available printers, select it

Step 16 – Press 'add'

That's it. The whole process should take about two minutes.

What the previous does is create a second Ethernet interface on both machines that use an IP address from the reserved 10.X.X.X range. This is what is known as a 'private address space', that is, IP addresses in the 10.X.X.X range are marked as being 'private' and with a few exceptions I won't get into here are not to be routed so this means that machines that are not physically attached to my local network can't use this address at all. The next trick is that Apple's default subnet mask for manually entered addresses is which means that all addresses in the 10.0.0.X range are automatically on the same subnet. So the end result is that both machines now have alternate locally routed only addresses that are on the same subnet. So, voila, CUPS work.

The previous describes Stuart's second solution, his first solution was to change the CUPS configuration to allow connections from computers that aren't on the same sub-domain. Then I would go to my wife's machine and manually create a printer queue that used my machines ".local" DNS address. The ".local" domain triggers the use of multicast DNS resolution. In other words when a computer looks for a DNS name like "foo.local" it will try to find the computer that owns that name by essentially 'yelling' out to all the local machines "hey, anyone go by the name foo?". While my wife and I's machines are on two separate subnets they are still physically connected by the same Ethernet switch and so can see each other's multicast packets. All OS X boxes give themselves ".local" names (go to System Preferences – Sharing – you should see text at the top that says "Other computers on your local subnet can access your computer at X.local") so by giving the Printer Queue my machine's .local name as its address my wife's machine would always be able to find my machine and it's attached printer even when my IP address is changed by DHCP.

I didn't like this suggestion for two reasons. First, I didn't like the idea of opening up my CUPS configuration, that sounded like a security hole since anyone that knew my IP address could now print on my machine. Although, if memory serves, it is possible to configure CUPS to provide access to specific DNS addresses so I could just have listed my wife's ".local" DNS address. Second, I like things to work automatically and having all these configurations in CUPS and in my wife's machine made me nervous. I wanted something simpler. Which is why I choose Stuart's second suggestion.

7 thoughts on “Sharing Printers Between OS X Boxes in a Screwed Up Local Network”

  1. It would be a whole bunch easier if you invest in a cheap broadband router ($30 -$35). It would give you a constant IP scheme and have the added benefit of a NAT firewall. Also, adding complexity to your network by “creating a second Ethernet configuration” is kind of a hack and might cause issues that are difficult to correct. Not saying that it’s a bad idea but it’s not nearly as secure as a NAT router and more of a hassle. Especially if you want to do things like use bittorrent to download pod casts, use a VPN or play an online game.

  2. Indeed, if I was suggesting a network configuration for a simple user I would urge them to get a NAT firewall for two reasons. One, having a separate hardware firewall reduces the user’s security exposure should they mis-configure the firewalls on their local machines (which they should be running anyway for security in depth). Using NAT is useful because ISPs tend to charge lots of extra money to get multiple IPs which is why NAT was invented in the first place, to make many computers look like one machine so you don’t have to pay your ISPs to get extra addresses.

    However there are definite downsides to using NAT in particular and external firewalls in general. NAT violates the end-to-end requirements of the Internet which calls for all machines to be able to talk directly to each other. This means that a number of protocols (such as the VPN used by my company) will fail if sent across a NAT because the protocol expects to encode its “real” address in the protocol but because of the way NAT works the machine’s “real” address is wrong because it isn’t the address the NAT is advertising.

    The problem with using an external firewall is that if you do want to expose external services (e.g. run a BitTorrent client/repeater) you have to both set up your local machine to accept incoming connections and then you have to go to your NAT/firewall box and ask it to also allow the incoming connection and make sure you properly configure the port forwarding rules. This is just ‘something else’ to go wrong and pretty much guarantees that any non-expert user will make a mistake.

    This problem is ugly enough that most new protocols go to painful and expensive contortions to get around it. For example, iChat is perfectly happy to allow direct peer-to-peer chatting (ala Bonjour based chat) but for the big ugly Internet Apple has to pay a bunch of money to host a huge server whose only purpose is life is to act as a kind of port forwarder. Instead of the user telling people they are chatting with to connect directly to their machine they have to tell people to connect to Apple’s big forwarding service and then they establish an outgoing connection to Apple’s servers who can then forward message traffic.

    The practical consequence is that anyone wanting to offer a successful peer-to-peer Internet service has to set up expensive forwarding servers to support firewall users who are too technically naive to configure forwarding rules (and to work around admins who won’t set up forwarding). There are some work arounds but they aren’t reliable. For example, one could make one’s client support UPnP’s port forwarding protocol to open ports on the firewall but what if the person’s firewall doesn’t support UPnP? The end result is that hardware firewalls make it much more expensive for small companies to be successful on the Internet because they now have to offer expensive forwarding servers ala Apple (or Skype who has to use the same trick) rather than being able to take advantage of the scalability and low cost of peer-to-peer protocols. Increasing the cost of offering services on the Internet doesn’t sound like a good idea to me.

    Also I’m not sure why you are worried by the second Ethernet configuration. OS X boxes use multiple network connections all the time. For example, you will have one connection for your Ethernet card, one for your wireless card, one for your VPN, one for your Bluetooth (if you are running IP over it), one for your Firewire card (again, if you are running IP), etc. So OS X is designed to deal with multiple network connections and the complexity it introduces.

  3. Yes, having multiple adapters (Ethernet, Wireless, Bluetooth, Firewire) is simple and of little consequence. A “second Ethernet configuration” is very different than a second adapter. If am reading the post correctly. You are configuring your computer to use the external subnet for Internet access and internal (10.0.0.x) subnet for local services like printing and file sharing. But you’re doing this over a single adapter and are potentially exposing your network. Subneting is a good way to control traffic but it is certainly not a secure method.

    Most NAT routers nowadays have VPN Passthrough (IPSec) and Port forwarding. Both are trivial to setup through a web browser interface. VPN Passthrough is usually on or off. So there is not much to screw-up unless your company doesn’t use IPSec. I wouldn’t blame them as IPSec has security issues of it’s own. The hardest part of Port forwarding is finding the proper ports to open. So on the client side not a whole lot to worry about. You do make an interesting point about costing money and causing problems for service providers. Although most services would put up the same servers to monitor traffic and control their service. So I think the benefits for the local security a NAT router provides far outweighs the extra resource eating from service providers.

  4. I’m not sure why you think exposing the internal address is a security issue, no router will forward traffic using an internal address so nobody can actually use it to access my network externally.

    Keep in mind that I do not use 802.11 so the only way to access my network is either physically or by taking over the router sitting in front of my internet connection at my ISP. I consider someone specifically targeting my ISP’s router to be sufficiently unlikely that I don’t worry about it.

    As for service providers, there is a huge difference between monitoring your traffic and having to route all content through your systems. If a service provider just wants to monitor their traffic they can easily have two channels, one that sends updates (and would be tiny) and one that handles content that is actually sent peer-to-peer. With hardware firewalls and clueless users the service provider is forced to host both the tiny status updates and the enormous content. That is a major barrier to entry.

    But, to be clear, the reason I don’t use a hardware NAT firewall is that I like to be able to run services and I don’t want yet another configuration to worry about.

  5. Do you have any familiarity with OS X server. I’m trying to do the same thing with server printers/fax and find myself stymied by the problem you address here.

    Additional complication:
    Default route is to internet via a 2nd ethernet card out of the server on IP issued by ISP.

    Servers location is 192.168.1.x on local network.
    Desired route for printers is via a router to two T1 connected remote locations. 192.168.2.x and 192.168.3.x

    Can’t get the shared printers on the remote sites as they are on different subnets of course. The problem I think I face is that because I’m running across multiple switches and routers there is no route available at the routers to send on this new “local” network to the right place.

    I tried your solution, no luck I assume due to routing issues.

    Any advice? Thanks for your time.

  6. I don’t have any experience with OS X server but I suspect part of the problem is that your multicast packets aren’t being seen at the remote systems. Unless explicitly configured to do so most routers won’t forward multicast packets, especially local area multicast packets. So the problem may not be your machine but your network configuration.

  7. Has anyone gotten this to work if the mac that wants to connect to the host printer wants to do it over airport? The host computer is set up using the Local Ethernet method. I tried setting up the MacBook with a “Local Airport” method – but no such luck.

    Thanks for any help…

Leave a Reply

Your email address will not be published. Required fields are marked *