Minecraft and Firewalls and OS X
Lots of people have trouble connecting LAN games on Minecraft. Recently, that's especially true of OS X. The information out there is so bad, I'm going to put down what I can find out (in a slightly flu-addled state).
Here's some suggestions I've seen - all wrong. I'm sure I'm wrong about some things, but I won't be wrong and certain.
Just click "allow incoming connections"
Problem one, you have to do this every time. Every time Minecraft starts, it requests to open a port, and it's a random high port. From monkeying with netcat (yeah, there's a good app to permit), it looks like the changing port number isn't the issue.
The second problem is that the dialog to allow the connection disappears behind any other window nearby. If you have full-screen configured, that means Minecraft itself obscures the dialog. If you are NOT in fullscreen mode, the dialog pops up when you click "Multiplayer". So there's one method. You'd think this would also work when opening a world to the LAN. It does, for a fraction of a second, then the dialog gets lost.
So here's an observation. Modern OSen still suck at modal dialogs. On Mountain Lion and Windows 7, I still have to go searching for dialogs all the time. They blink out of site, and aren't regular windows so you cant window-switch for them. WTF.
Anyway, no obvious solution here.
Open your firewall completely
Actually, as a short-term solution, this isn't horrible, maybe the best idea of the ones floating around. Not such a good idea, as eventually you will forget to turn it off.
Add Java to the allowed applications
This makes sense because the Minecraft application itself is just a fancy loader for Java, like the exe on Windows. So something about approving the application approves the stub loader, but Java is still untrusted, as it should be.
This is the worst idea of the lot because Java.
I'm not even going to test this one.
Change your application firewall settings from the command line
I found a page showing how to manipulate the ApplicationFirewall from the command line. Doesn't work, but I bet it would if I let Java get approved. Yeah, no.
That's a nice idea. I've got plenty of nice IPFW configuration sets for FreeBSD servers. However, this would mean disabling the application firewall and using this instead. It would definitely work, but you'd have to know OS X apps pretty well to know what ports you want.
Also, it's deprecated. OS X has moved to pf for more flexibility. And that's without even getting to the wrong or misinformed rules floating around. Also, which port are we allowing here? Minecraft keeps changing its upper port, and I don't even know what it's doing to scan the LAN.
For some reason, it's not all that easy to find out how Minecraft scans the LAN and makes connections. I tried with tcpdump. I've got the flu, I shouldn't be doing this. I tried Google. WTF, these aren't state secrets.
The Real Problems
It's amazing how many little things add up to a problem.
- Minecraft is popping itself up and hiding the modal dialogs.
- Modern OSen still suck at handling modal dialogs.
- Minecraft uses high ports for incoming traffic.
- Software documentation is getting worse. I'm picking on OS X here. Between "for dummies" documentation and developer documentation, there's not a lot of good documentation.
- Search engines are getting worse at finding documentation. The dark side of Page Rank is its reliance on popularity. Ignorant people commenting on popular sites get better results than actual documentation.
But really, how hard can it be to find documentation, right? Find out how Minecraft scans for LAN games. Find out how the Application Firewall works. Find out how to use pf rules to bypass the Application Firewall for particular ports.
The Minecraft Wiki contains information on how MC scans for LAN games. It was hard to find.
The Right Way
Pretty sure it's going to be manipulating PF. Using sudo or a root shell:
hostname /etc/pf.anchors} pfctl -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "com.apple/*" all fragment reassemble
Interesting. So Apple is using pf's "scrub" to clean up TCP packets, then passing everything to an internal ruleset. Let's see what's in there.
anchor "com.apple/*" all
hostname /etc/pf.anchors} pfctl -a com.apple -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "100.InternetSharing/*" all fragment reassemble
scrub-anchor "300.NetworkLinkConditioner/*" all fragment reassemble
anchor "100.InternetSharing/*" all
anchor "200.AirDrop/*" all
anchor "250.ApplicationFirewall/*" all
anchor "300.NetworkLinkConditioner/*" all
Well isn't that interesting. It does look like pf is the infrastructure. So a ruleset could be created to allow specific bypasses. A nice one would be something that could be turned on and off just for Minecraft.
Some other playing around suggests that pf isn't enabled, so those com.apple anchors are probably meant to replicate whatever OS-level stuff is being done. Maybe if I enable it, I can actually see what rules are in those sub-rulesets. I've never worked with pfctl anchors so far. That's enough stream-of-flu-state for now.
UPDATE: Code signing is a problem. I've had some fun playing with pf, but the bottom line is that the socketfilterfw seems to kick in regardless of pf rules. Here's an explanation of why some apps keep triggering the firewall dialog. I kinda get it. Kinda. I checked with "codesign -v" and it doesn't think much of Minecraft's sig. Minecraft does a self-update on start, which is probably why it kills the original allow/deny dialog. Essentially, don't start in fullscreen mode. Oh well.
If I have time, I'm going back to FreeBSD. On interesting thing is that /usr/libexec/ApplicationFirewall/com.apple.alf.plist has a section called explicitauths. It includes things like python, ruby, java... and nc. Which I had used for testing. At some point netcat was triggering the socketfilterfw. I went through various cycles of disabling and re-enabling it. Now it does not trigger it, even though it is not listed in the Preferences pane, and even though an attempt to reach it from outside gets blocked and logged (while localhost skips it). That's weird, but annoying stuff like that happens when you muck about, and a reboot could reset it.