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
next prev parent 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