I''m having a problem with DNAT. I''ve read the documentation and it seems straightforward, but I seem to be missing something and I''m not getting the result I expect. My understanding of the DNAT format in the rules file is: DNAT <sz> <dz>:<di>:<dp> <proto> <op> where: sz = Source Zone dz = Destination Zone di = Destination IP Address dp = Destination Port op = Original Port So I''d like request from net to my firewall at port 10201 to be redirected to port 22 on ip 192.168.65.201. So here''s the rule I have DNAT net loc:192.168.65.201:22 tcp 10201 When I run this, Shorewall appears to accept it. Rule "DNAT net loc:192.168.65.201:22 tcp 10201" added. But it doesn''t work- connections to 10201 get caught by the net2all policy. So I look at the output of iptables -L and see: ACCEPT tcp -- anywhere myhostname tcp dpt:ssh That doesn''t look superficially to me like it''s doing the right thing. Can someone please explain to me what I''m doing wrong? Thank you, - Serge Wroclawski
Serge Wroclawski wrote:> I''m having a problem with DNAT. I''ve read the documentation and it seems > straightforward, but I seem to be missing something and I''m not getting > the result I expect. > > My understanding of the DNAT format in the rules file is: > DNAT <sz> <dz>:<di>:<dp> <proto> <op> > > where: > sz = Source Zone > dz = Destination Zone > di = Destination IP Address > dp = Destination Port > > op = Original Port > > So I''d like request from net to my firewall at port 10201 to be redirected > to port 22 on ip 192.168.65.201. >Please see Shorewall FAQ #1c. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Mon, 3 May 2004, Tom Eastep wrote:> Please see Shorewall FAQ #1c.Yes, I read that, and I don''t see how my configuration is different. The example: #ACTION SOURCE DEST PROTO DEST PORT DNAT net loc:192.168.3:22 tcp 1022 My configuration: DNAT net loc:192.168.65.201:22 tcp 10201 Other than spacing issues, they look functionally identical to me. - Serge Wroclawski
Serge Wroclawski wrote:> On Mon, 3 May 2004, Tom Eastep wrote: > > >>Please see Shorewall FAQ #1c. > > > Yes, I read that, and I don''t see how my configuration is different. > > The example: > > #ACTION SOURCE DEST PROTO DEST PORT > DNAT net loc:192.168.3:22 tcp 1022 > > My configuration: > > DNAT net loc:192.168.65.201:22 tcp 10201 > > Other than spacing issues, they look functionally identical to me.That is the correct rule -- a) ''iptables -L'' is the most useless command ever invented. It tells you *nothing*. b) Are you running Mandrake and did you let Mandrake configure "Internet Connection Sharing"? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Serge Wroclawski wrote: > >> On Mon, 3 May 2004, Tom Eastep wrote: >> >> >>> Please see Shorewall FAQ #1c. >> >> >> >> Yes, I read that, and I don''t see how my configuration is different. >> >> The example: >> >> #ACTION SOURCE DEST PROTO DEST PORT >> DNAT net loc:192.168.3:22 tcp 1022 >> >> My configuration: >> >> DNAT net loc:192.168.65.201:22 tcp 10201 >> >> Other than spacing issues, they look functionally identical to me. > > > That is the correct rule -- > > a) ''iptables -L'' is the most useless command ever invented. It tells you > *nothing*.Let me elaborate: ''iptables -L'' without any additional options: a) Converts IP addresses into DNS names (or tries). It picks the first DNS name that it can find that resolves to the given IP address. b) It only covers the ''filter'' table c) It omits printing almost all match information (most importantly input interface and output interface). So, ''iptables -L'': a) Tells you nothing about SNAT, DNAT or MASQUERADE (those are handled in the ''nat'' table. b) Gives you misleading information about addresses. c) Gives you incomplete information about the rules that it displays. So if you want a complete picture of what your firewall rules look like, use ''shorewall status''. That command interates over the three major tables using the command ''iptables -t <table> -L -n -v". -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Serge Wroclawski wrote: Hi Serge,> My configuration: > > DNAT net loc:192.168.65.201:22 tcp 10201 > > Other than spacing issues, they look functionally identical to me.Just wondering why this isn''t working.. Your above rule..... (which looks perfectly fine),(And assuming that you are in fact starting an SSH connection from someone out on the Internet and not internally)..... I would edit the dnat line to log allowed connections for that specific rule... DNAT:info net loc:192.168.65.201:22 tcp 10201 # shorewall stop # shorewall start # shorewall logwatch now... have someone on the internet test your DNAT port-redirection rule.. and watch the output of "shorewall logwatch" What happens? Are you sure that tcp port 10201 isn''t in use or bound to an existing connection on either end of the connection before the client tries to ssh? HTH''s JBanks
Joshua Banks wrote:> Serge Wroclawski wrote: > Hi Serge, > >> My configuration: >> >> DNAT net loc:192.168.65.201:22 tcp 10201 >> >> Other than spacing issues, they look functionally identical to me. > > > Just wondering why this isn''t working.. >I suspect that the OP is running Mandrake so that the rule that works is: DNAT net masq:192.168.65.201:22 tcp 10201 -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> I suspect that the OP is running Mandrake so that the rule that works is: > > DNAT net masq:192.168.65.201:22 tcp 10201Ahhh. Yes.. I forgot that ManDrake does this.. Just out of Curiousity Tom why would they (MD), stray from (your Zone norm)? Since using Shorewall I don''t ever remember you using MASQ as a zone Ever... JBanks
Joshua Banks wrote:> Tom Eastep wrote: > >> I suspect that the OP is running Mandrake so that the rule that works is: >> >> DNAT net masq:192.168.65.201:22 tcp 10201 > > > > Ahhh. Yes.. I forgot that ManDrake does this.. Just out of Curiousity > Tom why would they (MD), stray from (your Zone norm)? Since using > Shorewall I don''t ever remember you using MASQ as a zone Ever...They are asking themselves the same question :-) -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:>> Joshua Banks wrote: >> Ahhh. Yes.. I forgot that ManDrake does this.. Just out of Curiousity >> Tom why would they (MD), stray from (your Zone norm)? Since using >> Shorewall I don''t ever remember you using MASQ as a zone Ever...> They are asking themselves the same question :-)To funny. I''m no programmer but it would seem an easy fix. Seems like laziness to me. Or no-one has bothered to touch the "Internet Connection Sharing" script thingy. Oh.. well.. JBanks
Joshua Banks wrote:> Tom Eastep wrote: > >>> Joshua Banks wrote: >>> Ahhh. Yes.. I forgot that ManDrake does this.. Just out of Curiousity >>> Tom why would they (MD), stray from (your Zone norm)? Since using >>> Shorewall I don''t ever remember you using MASQ as a zone Ever... > > >> They are asking themselves the same question :-) > > > To funny. I''m no programmer but it would seem an easy fix. Seems like > laziness to me. Or no-one has bothered to touch the "Internet Connection > Sharing" script thingy. Oh.. well..They have fixed the problem in 10.0 Public Edition (but not in the community edition). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> They have fixed the problem in 10.0 Public Edition (but not in the > community edition).One less thing you have to worry about once both Public and Community Editions are fixed then I guess.. ManDrake was my very first linux distro and the MASQ zone/variable messed with me from time to time before I was really comfortable with linux and shorewall.. :D JBanks
Tom Eastep wrote:> > I suspect that the OP is running Mandrake so that the rule that works is: > > DNAT net masq:192.168.65.201:22 tcp 10201 >Serge -- did this tip solve your problem? Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tom, found a little typo in install.sh of shorerwall-2.01.tgz (and probably earlier versions too) Don''t know if it is already known to the list... Line 528: if insserv /etc/init.d/shorewalls ; then So the "s" behind shorewall is too much and causes a insserv error of course. Guess this happens only on SuSE systems, at least I don´t know which distros are using insserv as well... Greetings and thank you for great work, Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAl99pn4yHpyS1rqARAig/AJ40dfHd8W7FQ6uSBHtdEgkkG5Ie6ACgrSu9 uFcUS4sKNRScq+F+JHbpS78=Hxef -----END PGP SIGNATURE-----
Alexander Wilms wrote:> > found a little typo in install.sh of shorerwall-2.01.tgz (and probably earlier > versions too)Thanks Alex! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 4 May 2004, Tom Eastep wrote:> Serge -- did this tip solve your problem?Sorry, no. I must have fat fingered my original reply and I''ve been completely swamped since. These are Fedora (soon to be RHE boxes). At home, all my systems are Debian so I know that a bit better, though I''ve used Red Hat in the workplace for 5 years. This shouldn''t matter except that apparently some silly systems like Mandrake muddle with the configuration. AFAIK none of mine do that. All the other iptable rules are off, and the default iptables thing Red Hat comes with is disabled. I want to state a few things that may make this easier. I don''t want a regular NAT in that the boxes behind the firewall host don''t need to talk to the outside[1]. I just need a few services tunneling through. Before shorewall, the ugly solution they had/have in place (until I get shorewall working) is rinetd, so I don''t need anything fancy. The host has two interfaces: net eth0 detect routefilter,norfc1918,tcpflags loc eth1 detect tcpflags,dhcp The policy appears simple and direct, though I''m unsure if I want/need the net to loc policy: fw net ACCEPT fw loc ACCEPT net loc ACCEPT (the rest of the policy is the default drop rules) I have a one line masq: eth0 eth1 Here''s a sample of the DNAT rules I have DNAT net loc:192.168.65.201:22 tcp 10201 Here''s a sample (obscured) of the resulting firewall log: May 7 09:27:36 myhost kernel: Shorewall:net2all:DROP:IN=eth0 OUTMAC=11:11:11:11:11:11:11:11:11:11:11:11:11:11 SRC=1.2.3.4 DST=2.3.4.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27749 DF PROTO=TCP SPT=34751 DPT=14201 WINDOW=5840 RES=0x00 SYN URGP=0 So it''s being caught by the net2all rule, meaning it isn''t being caught by the above rules. What else can I send? What obvious thing am I missing? - Serge Wroclawski
Serge Wroclawski wrote:> > I don''t want a regular NAT in that the boxes behind the firewall host > don''t need to talk to the outside[1]. > > I just need a few services tunneling through. Before shorewall, the ugly > solution they had/have in place (until I get shorewall working) is rinetd, > so I don''t need anything fancy. > > The host has two interfaces: > > net eth0 detect routefilter,norfc1918,tcpflags > loc eth1 detect tcpflags,dhcp > > The policy appears simple and direct, though I''m unsure if I want/need the > net to loc policy: > fw net ACCEPT > fw loc ACCEPT > net loc ACCEPT > > (the rest of the policy is the default drop rules) > > I have a one line masq: > > eth0 eth1 > > Here''s a sample of the DNAT rules I have > > DNAT net loc:192.168.65.201:22 tcp 10201 > > Here''s a sample (obscured) of the resulting firewall log: > > May 7 09:27:36 myhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=11:11:11:11:11:11:11:11:11:11:11:11:11:11 SRC=1.2.3.4 > DST=2.3.4.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27749 DF PROTO=TCP > SPT=34751 DPT=14201 WINDOW=5840 RES=0x00 SYN URGP=0 > > So it''s being caught by the net2all rule, meaning it isn''t being caught by > the above rules.a) Is 2.3.4.5 the primary IP address of eth0? b) What is the setting of DETECT_DNAT_IPADDRS in shorewall.conf? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 7 May 2004, Tom Eastep wrote:> > Here''s a sample (obscured) of the resulting firewall log: > > > > May 7 09:27:36 myhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT> > MAC=11:11:11:11:11:11:11:11:11:11:11:11:11:11 SRC=1.2.3.4 > > DST=2.3.4.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27749 DF PROTO=TCP > > SPT=34751 DPT=14201 WINDOW=5840 RES=0x00 SYN URGP=0 > > > > So it''s being caught by the net2all rule, meaning it isn''t being caught by > > the above rules. > > a) Is 2.3.4.5 the primary IP address of eth0?No. 2.3.4.5 is the IP I''m testing from on the outside- my workstation.> b) What is the setting of DETECT_DNAT_IPADDRS in shorewall.conf?DETECT_DNAT_IPADDRS=No - Serge Wroclawski
On Fri, 7 May 2004, Serge Wroclawski wrote:> No. 2.3.4.5 is the IP I''m testing from on the outside- my workstation.Erm. Sorry. I meant yes. It''s been a long three days. 2.3.4.5 is the primary IP of eth0. Sorry... I need more than 4 hours sleep apparently. - Serge Wroclawski
Serge Wroclawski wrote:> On Fri, 7 May 2004, Tom Eastep wrote: > > >>>Here''s a sample (obscured) of the resulting firewall log: >>> >>>May 7 09:27:36 myhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT>>>MAC=11:11:11:11:11:11:11:11:11:11:11:11:11:11 SRC=1.2.3.4 >>>DST=2.3.4.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27749 DF PROTO=TCP >>>SPT=34751 DPT=14201 WINDOW=5840 RES=0x00 SYN URGP=0 >>> >>>So it''s being caught by the net2all rule, meaning it isn''t being caught by >>>the above rules. >> >>a) Is 2.3.4.5 the primary IP address of eth0? > > > No. 2.3.4.5 is the IP I''m testing from on the outside- my workstation.(Strong curses about people who insist that IP addresses are state secrets). The above log message shows SRC=1.2.3.4, DST=2.3.4.5, IN=eth0 and OUT=. Therefore this is an *inbound* message on eth0 *from* 1.2.4.4 *to* 2.3.4.5 and the IP stack in your firewall''s kernel believes that 2.3.4.5 is an IP address belonging to the firewall. So I don''t understand your answer. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Serge Wroclawski wrote:> On Fri, 7 May 2004, Serge Wroclawski wrote: > > >>No. 2.3.4.5 is the IP I''m testing from on the outside- my workstation. > > > Erm. Sorry. I meant yes. It''s been a long three days. > 2.3.4.5 is the primary IP of eth0. > > Sorry... I need more than 4 hours sleep apparently. >Ok -- then please reproduce the problem and send me the output of "shorewall status" as an attachment. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Serge Wroclawski wrote:> On Fri, 7 May 2004, Serge Wroclawski wrote: > > >>No. 2.3.4.5 is the IP I''m testing from on the outside- my workstation. > > > Erm. Sorry. I meant yes. It''s been a long three days. > 2.3.4.5 is the primary IP of eth0. > > Sorry... I need more than 4 hours sleep apparently. >Ok -- then please reproduce the problem and send me the output of "shorewall status" as an attachment. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Serge Wroclawski wrote:> > The policy appears simple and direct, though I''m unsure if I want/need the > net to loc policy: > fw net ACCEPT > fw loc ACCEPT > net loc ACCEPTIt is neither needed nor wanted. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 7 May 2004, Tom Eastep wrote:> It is neither needed nor wanted.Hrm. It seems without that, I need explicitly allow services to loc, such as NTP. Is that right? - Serge Wroclawski
Serge Wroclawski wrote:> On Fri, 7 May 2004, Tom Eastep wrote: > > >>It is neither needed nor wanted. > > > Hrm. It seems without that, I need explicitly allow services to loc, such > as NTP. > > Is that right?The only way that you can have net->loc traffic at all is if you use DNAT rules. So having a net->loc ACCEPT policy doesn''t make any sense. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> > The only way that you can have net->loc traffic at all is if you use > DNAT rules. So having a net->loc ACCEPT policy doesn''t make any sense.In case it is not clear, the only policy I was objecting to is the net->loc policy. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net