I''m tyring to provide a support vendor with SSH access to an internal machine. When I configured shorewall to forward port 8022 from the firewall to port 22 on the internal host, it didn''t work -- the vendor was being prompted for authentication to the firewall, and not the internal host! ## This does not work: ACCEPT net:W.X.Y.Z loc:192.168.0.107:22 tcp 8022 - A.B.C.D (W.X.Y.Z = public IP of support vendor; A.B.C.D = public IP of my firewall) When I change the rule to forward port 22 to the internal machine, it worked just fine. ## This works: ACCEPT net:W.X.Y.Z loc:192.168.0.107:22 tcp 22 - A.B.C.D (W.X.Y.Z = public IP of support vendor; A.B.C.D = public IP of my firewall) I guess the second format is better in the long run, since this vendor has no business ssh''ing to our firewall... But I''m still curious: can anyone tell me what I did wrong? Thanks, Scott
I should qualify my message a bit: The symptom I describe would occur if the support vendor were trying to connect to port 22 on the firewall instead of port 8022. They _told_ me they were trying on port 8022, but since they''re several states away, I can''t really confirm it. =) If my original configuration attempt was correct, then it was most likely miscommunication between me and the vendor. Thanks, Scott ----- Original Message ----- From: "Scott Merrill" <smerrill@finelinegraphics.com> To: <shorewall-users@shorewall.net> Sent: Thursday, March 14, 2002 11:45 AM Subject: [Shorewall-users] SSH port forward> I''m tyring to provide a support vendor with SSH access to an internal > machine. > > When I configured shorewall to forward port 8022 from the firewall to port > 22 on the internal host, it didn''t work -- the vendor was being promptedfor> authentication to the firewall, and not the internal host! > > ## This does not work: > ACCEPT net:W.X.Y.Z loc:192.168.0.107:22 tcp 8022 - > A.B.C.D > (W.X.Y.Z = public IP of support vendor; A.B.C.D = public IP of myfirewall)
Scott, ----- Original Message ----- From: "Scott Merrill" <smerrill@finelinegraphics.com> To: <shorewall-users@shorewall.net> Sent: Thursday, March 14, 2002 8:55 AM Subject: Re: [Shorewall-users] SSH port forward> I should qualify my message a bit: > The symptom I describe would occur if the support vendor were trying to > connect to port 22 on the firewall instead of port 8022. They _told_ me > they were trying on port 8022, but since they''re several states away, I > can''t really confirm it. =)You could have confirmed it at the time by looking at the output of "shorewall show nat" -- there would have been a rule that DNATed both the ip address and the port number. If the packet count was zero, the vendor wasn''t trying to connect on 8022.> > If my original configuration attempt was correct, then it was most likely > miscommunication between me and the vendor.Your original configuration was correct -- your vendor apparently was trying to connect to port 22. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Scott Merrill wrote:> I''m tyring to provide a support vendor with SSH access to an internal > machine. > > When I configured shorewall to forward port 8022 from the firewall to port > 22 on the internal host, it didn''t work -- the vendor was being prompted for > authentication to the firewall, and not the internal host! > > ## This does not work: > ACCEPT net:W.X.Y.Z loc:192.168.0.107:22 tcp 8022 - > A.B.C.D > (W.X.Y.Z = public IP of support vendor; A.B.C.D = public IP of my firewall) > > When I change the rule to forward port 22 to the internal machine, it worked > just fine. > ... But I''m still curious: can anyone > tell me what I did wrong?I suspect you might be seeing an ssh bug, not a shorewall bug. On my (Red Hat 7.2) system, if i have this in my ~/.ssh/config: Host internal_host HostName firewall_host Port 8022 i actually get prompted for the password at firewall_host. It still port forwards correctly to internal_host, but it is displayed as firewall_host. Did they actually try the password? I think it might have worked. (Alternatively, they probably just forgot the ''-p 8022''. :-) PDG