I hate java.

I might have mentioned that before.  In case I didn’t…I hate java.  Now, today’s issue didn’t come directly because of java but it was the result, and an obscure one at that.

I’ve been struggling with a client issue that basically boiled down to slow or non-responsive websites that were passing through IOS firewalls.  Most websites would work fine and if we re-routed the traffic to another outbound connection that had an ASA it would work perfectly.  Also, if we connected a laptop directly to these remote site internet connections it would be smooth sailing.  So obviously something was unhappy on the IOS firewall.  I tried changing MTU, MSS, disabling the websense (urlfilter) connection.  All kinds of different things!  Nothing made a bit of difference.

I decided to run the Tweak Test over at dslreports.com to see what the MTU and MSS results would be, thinking that’s still what I needed to fix.  Tweak test is a java applet.  I had someone onsite run it and I happened to be watching the console at the same time.  All of a sudden I start seeing “FW-3-HTTP_JAVA_BLOCK” messages popping up.  WTH!  So, I figure out that java is blocked by default on IOS firewall.  Here’s the fix:

access-list 3 permit any
ip inspect name inspect http java-list 3

Yep, basically add the acl for any and then add java-list to the end of the http inspect.  I also have a urlfilter on the end to maintain the websense checks.  ARGH!  I decided to try my problematic website, of which enterprise.com happens to be one, and it popped right up.  I never got an error message about java before trying to run this app on dslreports.com.  I never saw reference to a Java problem in any of my debugs.

I know this wasn’t java’s fault directly, but if java wasn’t such a piece of garbage it might not have to be blocked by default.

Leave a Reply

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