Thanks for the quick reply. I haven't had a chance to try your suggestion (I'm at work and this setup is at home), but I did more debugging last night, and I found some interesting things. Using tcpdump, I found that the SYN packet from the SSH tunnel comes out of a random port (the tunnel endpoint) and is routed to port 80 on the loopback. That's SSH at work. Then it does in fact get redirected to the server:80 by my rdr rule. The server responds with a SYN ACK and sends it to the tunnel endpoint. This is where things break. Something (either SSH or the other side of the tunnel - I haven't determined if the SYN ACK makes it that far) sends a RST packet back to the server. This pattern continues a couple of times until the browser gives up. The interesting thing is that the SYN ACK is coming from the server's address- i.e. the initial SYN goes to port 80 on the router, and is rerouted to the server address. The SYN ACK still has the server's address when it hits the tunnel end point. Could this be the source of the problem? Do I need to rewrite the source address to be the router address? Maybe with a NAT rule? I was attempting something like that last night, but I wasn't sure which interface it should go on. I'm thinking maybe the external (I think I tried the internal and loopback before going to bed).
As for why I don't just use a tunnel to the server directly, that requires knowledge of the server's address. If I want to let someone else access the server, I don't necessarily want them to know how the inside of the network is set up. i.e. which service is on what server etc. Allowing them to tunnel to the router and redirecting their traffic accordingly provides their traffic with encryption (I could just use HTTPS for encryption, but there will be several servers of different types and having everything in a tunnel means you can't tell what type of traffic is passing through), but allows me to move servers around at will. Ed --
