WatchGuard Gotcha

I ran into a nasty gotcha today. For the past few years we’ve recommended, sold, installed and configured Juniper SRX firewalls. They’re extremely flexible and can be made to do just about anything but they have one major drawback: the web console sucks! It’s slow, clunky, unintuitive, constantly crashes and is obviously a bolt-on to the command line interface.

Anyway, we decided to start implementing some of the WatchGuard “T” series firewalls because they have a very slick web console that is almost the complete opposite of the SRX: fast, smooth, intuitive, and stable. The command line interface on the WatchGuards is pretty weak but that’s a topic for another post.

So back to my gotcha. I needed to provide external access to a phone system listening on TCP ports 8000-8002. I configured the SNAT and the firewall policy but when testing from an external location I could only telnet into port 8001. Huh?

Well, the first troubleshooting task is obvious: telnet to all three ports from a device inside the firewall. I did this and got a response from ports 8000 and 8001 but not 8002 so that explains why I couldn’t connect to 8002 from the outside. But what about port 8000?

I configured the firewall policy to send the traffic over to a Windows server instead of the phone system, fired up my beloved Wireshark and tested telnetting into the three ports from the outside. Sure enough, ports 8001 and 8002 made it to the server but port 8000 did not. I changed the port range from 7900-8010, re-tested and all ports but 8000 made it through. Oy vey! Fortunately, a quick Google search on “watchGuard tcp 8000” revealed that by default WatchGuard blocks a number of ports that it deems particularly unsafe and sure enough, TCP 8000 is one of them. Once I removed that entry from the “blocked ports” list everything worked perfectly.  I hate when software tries to save you from yourself for exactly this reason but at least now I know and won’t get stung by this one again.