On 2008/01/22 21:27, Samuel Penn wrote: > As a followup however, I now have some success. I've been testing the > remote interface from work, which blocks unknown outgoing ports which > includes 5280, so the rule I actually had was to redirect a different > external port which was allowed by work's firewall onto 5280 internally. > > I was using port 21 (ftp), since I know that was allowed. Having just > changed that to 5223, it has started working.
FTP is a special case since a firewall usually examines commands on the control channel (port 21) to open/close ports and, if NAT is used, to adjust the addresses in PORT commands and responses to PASV. Running a non-FTP protocol on that port may well confuse things. (Some firewalls also try and verify that packets match their idea of what "should" be sent on a particular port). > My understanding from the > FAQ was that this shouldn't make any difference, since the filter rules > 'see' the port after the rdr has been applied, so the 'pass in quick' > for port 5280, should kick in even though it has come in on port 21. That's right. > My reading of the FAQ could be wrong (likely), or maybe lynx just > doesn't like being told to use port 21 for http. That works fine, you can test it with nc(1) - in one window, # nc -l 127.0.0.1 21 in another, $ lynx http://127.0.0.1:21/ then type something vaguely resembling an HTTP response into the nc window (actually Lynx doesn't care, just type anything at it :-) and ^D.
