Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Joel Newkirk <netfilter@newkirk.us>
To: Tom Elsesser <telsesser@mindspring.com>, netfilter@lists.netfilter.org
Subject: Re: Port forwarding problem
Date: Sun, 24 Nov 2002 15:40:28 -0500	[thread overview]
Message-ID: <200211241540.28168.netfilter@newkirk.us> (raw)
In-Reply-To: <ut86tuo7rimkt2dc52ke1qo8boaqtt29g0@4ax.com>

On Wednesday 13 November 2002 11:29 pm, Tom Elsesser wrote:
> Hi,
>  I have 2 linux servers on a 20 workstation network. There is an adsl
> connection coming thru a EN5861 router which connects to one server
> (yzerman) on eth1. Eth0 on this box goes to a 48 port switch. The
> other linux box (ulysses) is going to be a webmail server, and has 1
> nic going to the switch. I have the apache server on ulysses listening
> on port 8000. The router can forward ports but only on its own subnet,
> which is the same as eth1 on yzerman. I am trying to get port 8000 to
> go thru yzerman to ulysses, but can't seem to get it right. Can
> someone take a peek at my iptables config and tell me where I went
> wrong?

You need a few rules to allow this:  DNAT incoming port 8000 requests, accept 
those in FORWARD, accept returning in FORWARD.  (Once DNATted they are 
packets to be forwarded to another machine, not INPUT for the local firewall 
machine)

I've commented throughout the script below.  Is this your complete ruleset?


> Thanks in advance.
>
> +++++++++++++++++
> #!/bin/sh
>
> # Turn on ipforwarding just in case
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> # Flush old rulesets
> /sbin/iptables -F
> /sbin/iptables -F -t nat
>
> # Default policies
> /sbin/iptables -P INPUT ACCEPT
> /sbin/iptables -P OUTPUT ACCEPT
> /sbin/iptables -P FORWARD DROP

I'd STRONGLY suggest that for everyday use you set at least INPUT policy to 
DROP as well, and ACCEPT only traffic that legitimately should be granted 
access to the firewall machine.  Webmail traffic will (with proper 
configuration) all go through FORWARD, as will masqueraded LAN traffic.
Only connections to yzerman itself should ever be in INPUT, and only 
connections you explicitly want to allow to your firewall should ever be 
ACCEPTed in INPUT.

> # Masq out eth1 (to router)
> /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Fine here, but if your IP is static just SNAT, there's a lot less overhead if 
netfilter doesn't need to constantly double-check the firewall's IP.

> # Allow packets to return
> /sbin/iptables -A FORWARD -i eth1 -m state --state RELATED,ESTABLISHED
> -j ACCEPT
>
> # Allow packets out
> /sbin/iptables -A FORWARD -i eth0 -s 10.1.1.0/8 -j ACCEPT

If this is all the FORWARD rules you have, then you'll have problems.  You 
have a default DROP policy for FORWARD, which is good, but here you only 
allow EST/REL connections back from the internet (allows MASQ back through) 
and connections out from the LAN.  You need to also allow the DNATted 
connections through FORWARD, IE the INPUT --dport 8000 rule below should be 
in FORWARD, since that's where the DNATted packets are bound.  Your rule 
construction also doesn't allow connections from the LAN to forward to 
ulysses.  Is this the way you want it?  It's quite a bit more complicated to 
allow that, but can certainly be done.


> # Forward squirrelmail http request to ulysses
> /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 8000 -j
> DNAT --to 10.1.1.2
>
> # Connect to port 8000 (squirrelmail) from outside
> /sbin/iptables -A INPUT -i eth1 -d 0/0 -p tcp --dport 8000 -j ACCEPT

As said above, port 8000 is FORWARD traffic for the firewall after DNATting, 
not INPUT.

> # Connect via ssh from outside
> /sbin/iptables -A INPUT -i eth1 -d 0/0 -p tcp --dport 22 -j ACCEPT

Is this intended to allow SSH from the internet to the firewall?  That's what 
it currently does.  With ACCEPT policy on INPUT this is redundant anyway, but 
you should really default DROP, then allow specific cases through.  Again, no 
provisions for SSH from the LAN - is that something you want?  Currently the 
ACCEPT policy would allow that anyway, so the net effect right now is that 
SSH connections from the internet to the firewall machine are counted 
separately, and all traffic into the firewall machine is accepted.  NOT a 
particularly secure arrangement...  (actually about as unsecure as it could 
get, barring ACCEPT policy on FORWARD...)

> # Log to syslog
> # /sbin/iptables -A INPUT -j LOG


My suggestions would be:

Set default DROP policy for INPUT and FORWARD.  

Accept EST/REL in FORWARD without matching source/dest/in/out, or set up 
multiple state rules to allow both directions.  (only difference is multiple 
rules allow you to see traffic volume in each direction separately with 
iptables -L -v -n)  Personally I would have 4 EST/REL rules in FORWARD: one 
each for in and out from Ulysses, followed by one each for in and out from 
LAN in general.  This gives more detailed records without actually LOGging.

DNAT port 8000 to Ulysses, then ACCEPT in FORWARD. 

MASQ outbound connections to internet NOT from Ulysses.  (webmail replies will 
be reverse NATted automatically)

ACCEPT specific port connections in FORWARD coming from the LAN, IE allow 
TCP80, TCP/UDP53, etc.

Set a REJECT rule at the end of FORWARD for anything not allowed that came 
from the LAN, let not allowed from the internet just DROP silently.

Repeat for emphasis:  DROP INPUT to the firewall except for things that REALLY 
need to communicate directly to that machine.  If you want to be polite (to 
the LAN at least) you can REJECT instead of DROP, but from the outside world 
you really should DROP.

If the firewall machine itself has no reason to communicate directly with 
anything else (apart from forwarding) set a default REJECT policy on OUTPUT, 
and LOG anything reaching policy.  The only times this would matter is if 
someone is using the firewall box as a workstation, a server, or it has been 
compromised.

j



  reply	other threads:[~2002-11-24 20:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-14  4:29 Port forwarding problem Tom Elsesser
2002-11-24 20:40 ` Joel Newkirk [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-28  8:14 port " oarojo
2003-01-29  1:21 ` Arnt Karlsen
2003-01-29  0:56 Ian McBeth
2003-02-11 18:21 Port " Danila Octavian
     [not found] <001601c2d1fa$669894e0$990da8c0@..153.service>
2003-02-11 19:11 ` DarKRaveR
2003-02-11 19:14 ` Rob Sterenborg
2003-02-25 18:06 Port Forwarding Problem Tom Smith
2003-02-25 20:14 ` Willi Dyck
2003-02-25 21:53   ` Tom Smith
2003-02-26  3:20 ` Arnt Karlsen
     [not found]   ` <3E5C3DEE.70104@openadventures.org>
2003-02-26 14:07     ` Arnt Karlsen
2005-04-15 10:34 Julian Labuschagne
2005-04-15  8:40 ` Samuel Díaz García
2005-04-15 11:23   ` Julian Labuschagne
2005-04-15 14:32   ` Taylor, Grant
2005-04-15 14:40   ` Jason Opperisano
2005-04-15 10:36 Julian Labuschagne
2005-07-18  5:17 George Esperanza
2008-04-24 19:17 Ivan Hernandez
2008-04-25 19:49 ` Grant Taylor
2010-10-16 12:53 Port forwarding problem Carlos Mtz-Troncoso
2010-10-16 13:13 ` Pascal Hambourg
2010-10-16 13:19   ` Carlos Mtz-Troncoso
2010-10-16 13:37     ` Pascal Hambourg
2010-10-16 14:01       ` Carlos Mtz-Troncoso
2010-10-16 18:19         ` Pascal Hambourg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200211241540.28168.netfilter@newkirk.us \
    --to=netfilter@newkirk.us \
    --cc=netfilter@lists.netfilter.org \
    --cc=telsesser@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox