<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/5/2012 1:37 AM, Tim wrote:<br>
    </div>
    <blockquote
      cite="mid:1349426248.3229.24.camel@suspishus.lan.cameratim.com"
      type="cite">
      <pre wrap="">On Thu, 2012-10-04 at 12:45 -0700, Mark Space wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">I'm not sure where I could have fubared this. I did try to redirect
the ports from 80 to 8080, perhaps that was done incorrectly?
</pre>
      </blockquote>
      <pre wrap="">
You've tested that you can browse to localhost on port 80, but have you
also tested that web server is listening to port 8080, by browsing to
that port on the same machine (or over ssh)?</pre>
    </blockquote>
    <br>
    Yes, I tested that as well.  See below.<br>
    <br>
    <blockquote
      cite="mid:1349426248.3229.24.camel@suspishus.lan.cameratim.com"
      type="cite">
      <pre wrap="">

Why are you redirecting, though?  If there's a block on port 80, then
your attempt to get in on port 80 and redirect to port 8080 isn't going
work.  Which way are you *trying* to redirect?</pre>
    </blockquote>
    <br>
    <br>
    Just that I understand it's good practice to never run apps as
    root.  If I listen on port 8080 instead of 80, I never have to run
    the server as root.  Port 80 is completely unblocked, I have full
    control over it.  That's why I'm redirecting from port 80--it
    wouldn't make much sense to do so if that port was blocked.<br>
    <br>
    <br>
    <blockquote
      cite="mid:1349426248.3229.24.camel@suspishus.lan.cameratim.com"
      type="cite">
      <pre wrap="">

Last time I played with redirection (long ago), I did it to the input
and/or NAT rules, not the output rules. </pre>
    </blockquote>
    <br>
    <br>
    I do have a nat rule in that list.  The other two rules I think are
    to: 1. redirect output from the server itself on the loopback, and
    2. redirect output from the server itself on the external ip/nic. 
    In other words, if you try to connect internally, like I did from
    the command line with wget, it won't work unless you have those
    redirects.  I got the rules from the 'net;  I guess someone was just
    being thorough.<br>
    <br>
    Anyway, problem got solved.  I'll post a copy of this here (I
    already sent this reply to one of Bill's emails), as sometimes it
    seems emails on this list get lost or ignored.  The solution is good
    enough that some other folks might want to see it.  Someone with
    very good knowledge of TCP and unix pointed out:<br>
    <br>
    1.  I need to make sure port forwarding is enabled (it wasn't): <code>sudo
    </code>sysctl -w net.ipv4.ip_forward=1<br>
    <br>
    2. I *am* getting a response from the server.  If you look closely
    at the tcpdump output, the server is responding.  It's sending
    resets back the the external workstation.  That means it's telling
    the workstation that it saw the request, but there's no one
    listening.<br>
    <br>
    3. Close inspection with netstat on the server revealed I was
    listening on the right port, but the wrong network.  JBoss comes
    configured by default to listen on the loopback interface.  I had
    neglected to edit the config to tell it to listen on 0.0.0.0/0. 
    Grrrr.  That's distinct from the port, which is in a different part
    of the config file.  Grrr grrr.<br>
    <br>
    <br>
    I really hate system administration.<br>
    <br>
    Thanks for your help btw, and thanks to everyone else who tried to
    help.  It was useful to at least have avenues to pursue.<br>
  </body>
</html>