IPTables port forwarding issues

Hi all,

Sorry i know this is covered on the net in various places, but i
cannot seem to get what seems straight forward stuff working, by
trying various different solutions. Below is a unfinished firewall
script that is currently used in a test setup. I cannot however get
port 9023 to port forward from the firewall to an internal boxes ip
address. When I used nmap it returns filtered? Any suggestions on what
im missing here? In the test setup this box is providing natted
internet access.

I have marked the latest attempted lines i have been attempting to use
with !!! in the comment line. Please help this is driving me insane :(

Thanks in advance

(Trying to forward port 9023 from interface eth6, to an ip attached to
interface eth5). Ethername conventions below MAIN and WAN.




echo Flushing everything in the current setup
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

echo Setup default policies to handle unmatched traffic to drop all
traffic
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

echo Setup ethernet name conventions
export MAIN=eth5
export NET1=eth4
export NET2=eth0
export WAN=eth6
export LOOPBACK=lo
#export VPN=tap0
#export VPNBR=br0

export IPVPNMAIN=192.168.1.6
export IPVPNBRIDGE=192.168.1.7
export EXTERNALIP=xxx.yyy.zzz.ttt

echo Allowing incomming links from all network adapters to SSHD -
Seperate rules
iptables -A INPUT --protocol tcp --dport 10589 -i ${MAIN} -j ACCEPT
iptables -A INPUT --protocol tcp --dport 10589 -i ${NET1} -j ACCEPT
iptables -A INPUT --protocol tcp --dport 10589 -i ${NET2} -j ACCEPT
iptables -A INPUT --protocol tcp --dport 10589 -i ${WAN} -j ACCEPT

echo Open external port to be forwarded next, for OpenVPN SSH Remote
Access
iptables -A INPUT --protocol tcp --dport 9023 -i ${WAN} -j ACCEPT

echo Allowing incomming links porwarded to VPN Machine for SSH Links
#iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT --
to ${IPVPNMAIN}:9023

echo Setup Logging and destruction of Spoofed Internal packets, not
created from external networks
iptables -A INPUT -j LOG -i ${MAIN} \! -s 192.168.1.0/24
iptables -A INPUT -j LOG -i ${NET1} \! -s 192.168.11.0/24
iptables -A INPUT -j LOG -i ${NET2} \! -s 192.168.12.0/24
iptables -A INPUT -j DROP -i ${MAIN} \! -s 192.168.1.0/24
iptables -A INPUT -j DROP -i ${NET1} \! -s 192.168.11.0/24
iptables -A INPUT -j DROP -i ${NET2} \! -s 192.168.12.0/24

echo Block packets from network addresses outside of the source
address range - IP Spoofing
iptables -A INPUT -j LOG \! -i ${MAIN} -s 192.168.1.0/24
iptables -A INPUT -j LOG \! -i ${NET1} -s 192.168.11.0/24
iptables -A INPUT -j LOG \! -i ${NET2} -s 192.168.12.0/24
iptables -A INPUT -j DROP \! -i ${MAIN} -s 192.168.1.0/24
iptables -A INPUT -j DROP \! -i ${NET1} -s 192.168.11.0/24
iptables -A INPUT -j DROP \! -i ${NET2} -s 192.168.12.0/24

echo Protect loopback systems from IP Spoofing
iptables -A INPUT -j DROP -i \! ${LOOPBACK} -s 127.0.0.0/255.0.0.0

echo Allowing previously initiated and accepted exchanges bypass
remaining rule checking
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i ${WAN} -p \!
icmp -j ACCEPT

echo Allow all connections from the localhost
iptables -A INPUT -j ACCEPT -i ${LOOPBACK}

echo Allowing connections to Squid Proxy Server from dialer networks
iptables -A INPUT --protocol tcp --dport 3128 -i ${NET1} -j ACCEPT
iptables -A INPUT --protocol tcp --dport 3128 -i ${NET2} -j ACCEPT

echo Allowing DNS Forwarder and Caching hosted by this server to be
accessed by everyone but not WAN
iptables -A INPUT -p UDP --dport 53 -i ${MAIN} -j ACCEPT
iptables -A INPUT -p UDP --dport 53 -i ${NET1} -j ACCEPT
iptables -A INPUT -p UDP --dport 53 -i ${NET2} -j ACCEPT

echo Allow all connections from the Network Servers
iptables -A INPUT -s 192.168.1.5 -j ACCEPT
iptables -A INPUT -s 192.168.11.5 -j ACCEPT
iptables -A INPUT -s 192.168.12.5 -j ACCEPT


### NOTE NOT REQUIRED ALL OUTGOING ALLOWED ### -> To be corrected
later
# echo Allow DNS Resolution
# iptables -A OUTPUT -o ${WAN} -p udp --destination-port 53 -m state --
state NEW,ESTABLISHED -j ACCEPT
# iptables -A OUTPUT -o ${WAN} -p tcp --destination-port 53 -m state --
state NEW,ESTABLISHED -j ACCEPT

echo Lock down system services to the main network only
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ${MAIN} -j ACCEPT
iptables -A INPUT -p UDP --dport bootps -i ! ${MAIN} -j REJECT
iptables -A INPUT -p UDP --dport domain -i ! ${MAIN} -j REJECT

echo Dropping any other outside generated connections
iptables -A INPUT -m state --state NEW -i ${WAN} -j DROP

#echo Enabling IP Masq to enable NAT style internet IP Redirection
Access
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

# !!! THESE ARE ATTEMPTED PORT FORWARDING RULES CURRENTLY NOT WORKING :
(
iptables -A FORWARD -i ${WAN} -o ${MAIN} -p tcp --dport 9023 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -d ${EXTERNALIP} --dport 9023 -m
state --state NEW,ESTABLISHED,RELATED -j DNAT --to ${IPVPNMAIN}:9023
iptables -t nat -A POSTROUTING -d ${IPVPNMAIN} -s 192.168.1.0 -p tcp --
dport 9023 -m state --state NEW,ESTABLISHED,RELATED -j SNAT --to $
{IPVPNMAIN}

Re: IPTables port forwarding issues

fubar2007@googlemail.com wrote:
> Sorry i know this is covered on the net in various places, but i
> cannot seem to get what seems straight forward stuff working, by
> trying various different solutions. Below is a unfinished firewall
> script that is currently used in a test setup. I cannot however get
> port 9023 to port forward from the firewall to an internal boxes ip
> address. When I used nmap it returns filtered? Any suggestions on what
> im missing here? In the test setup this box is providing natted
> internet access.
[...]
> echo Flushing everything in the current setup
> iptables -F INPUT
> iptables -F OUTPUT
> iptables -F FORWARD
>
> echo Setup default policies to handle unmatched traffic to drop all traffic
> iptables -P INPUT DROP
> iptables -P OUTPUT ACCEPT
> iptables -P FORWARD ACCEPT

As a side-note: you should set the default policies before flushing the
chains. Also you should delete user-defined chains.

[...]
> echo Allowing incomming links porwarded to VPN Machine for SSH Links
> #iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT
> --to ${IPVPNMAIN}:9023

That line is supposed to do the trick, except that you could've omitted
the port in the --to since you don't redirect to a different port.

iptables -t nat -A PREROUTING -I ${WAN} -p tcp --dport 9023 -j DNAT \
--to ${IPVPNMAIN}

Does this fail? If so: what did the logs say about incoming packets on
that port?

[...]
> #echo Enabling IP Masq to enable NAT style internet IP Redirection Access
> iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
>
> # !!! THESE ARE ATTEMPTED PORT FORWARDING RULES CURRENTLY NOT WORKING :
> (
> iptables -A FORWARD -i ${WAN} -o ${MAIN} -p tcp --dport 9023 -m state
> --state NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A PREROUTING -t nat -p tcp -d ${EXTERNALIP} --dport 9023 -m
> state --state NEW,ESTABLISHED,RELATED -j DNAT --to ${IPVPNMAIN}:9023

You're thinking too complicated. DNAT merely rewrites the destination
address before the packet enters the actual filtering chains (see the
NAT-HOWTO [1]). Do the filtering in the filtering chains where it
belongs:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
-j ACCEPT

> iptables -t nat -A POSTROUTING -d ${IPVPNMAIN} -s 192.168.1.0 -p tcp --
> dport 9023 -m state --state NEW,ESTABLISHED,RELATED -j SNAT --to $
> {IPVPNMAIN}

You don't need SNAT, because you're already doing Masquerading (which is
a special form of SNAT).

[1] http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-6.ht ml#ss6.2

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: IPTables port forwarding issues

Hi thanks for the response, unforunately not there yet :(. I changed
the default policys to set before the chain flushes thanks.

The line

iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT
> --to ${IPVPNMAIN}:9023 does not give any errors when run.

Regarding the logs do you know where i would find these on gentoo
linux 2.6.19-release-r5? I looked in /var/log/messages but there was
only system general logging, no iptables from what i could see.

Is there a sepecial command in the firewall script i need to log
tracking of how iptables parses its connections through the various
chains?

Thanks again for all the help.

Re: IPTables port forwarding issues

fubar2007@googlemail.com wrote:
> The line
>
> iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT
> --to ${IPVPNMAIN}:9023 does not give any errors when run.

It may be just a typo, but it's supposed to read PREROUTING, not
PREROUTUING. And no, the line isn't supposed to raise an error, as the
syntax is correct AFAICS (aside from said typo).

> Regarding the logs do you know where i would find these on gentoo
> linux 2.6.19-release-r5? I looked in /var/log/messages but there was
> only system general logging, no iptables from what i could see.

I'm not familiar with Gentoo, but I'd try /var/log/syslog. And of course
you need advise netfilter to create log entries first by adding a
logging rule at the end of each chain. Also I need to correct my
previous suggestion: of course you need to allow the forwarded packets
in the FORWARD chain, not in the INPUT chain. Sorry.

iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \
--to ${IPVPNMAIN}

# ... <- INPUT chain rules go here
iptables -A INPUT -j LOG # log everything else

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
-j ACCEPT
# ... <- more FORWARD chain rules go here
iptables -A FORWARD -j LOG # log everything else

iptables -A POSTROUTING -j SNAT -o ${WAN} --to ${EXTERNALIP}

> Is there a sepecial command in the firewall script i need to log
> tracking of how iptables parses its connections through the various
> chains?

You mean how the packets flow through the chains? That's well-defined,
see e.g. [1].

[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: IPTables port forwarding issues

Ansgar -59cobalt- Wiechers wrote:


>> Is there a sepecial command in the firewall script i need to log
>> tracking of how iptables parses its connections through the various
>> chains?
>
> You mean how the packets flow through the chains? That's well-defined,
> see e.g. [1].
>
> [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

I recommend looking at:

http://www.netfilter.org/documentation/HOWTO//packet-filteri ng-HOWTO-6.html

and on that picture you see that the INPUT chain will filter no packets for
targets not adressed to the filtering host. All filtering of NATTED packets
is done in the FORWARD chain, never in INPUT.

I'd simply recommend loading the rules and then
iptables -nvL
and
iptables -nvL -t nat

to see the loaded ruleset.

To see where the packets go I'd add

iptables -A FORWARD -j LOG --log-prefix "debug "

as the first rule of FORWARD chain and some grep on the logfile afterwards.

Assuming a pretty normal config of syslog or syslog-ng the logs from the
packet filter should be found either in /var/log/messages
or /var/log/firewall or so,

Wolfgang

Re: IPTables port forwarding issues

Wolfgang Kueter wrote:
> Ansgar -59cobalt- Wiechers wrote:
>>> Is there a sepecial command in the firewall script i need to log
>>> tracking of how iptables parses its connections through the various
>>> chains?
>>
>> You mean how the packets flow through the chains? That's well-defined,
>> see e.g. [1].
>>
>> [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
>
> I recommend looking at:
>
> http://www.netfilter.org/documentation/HOWTO//packet-filteri ng-HOWTO-6.html
>
> and on that picture you see that the INPUT chain will filter no
> packets for targets not adressed to the filtering host. All filtering
> of NATTED packets is done in the FORWARD chain, never in INPUT.

What exactly does that ASCII drawing show that's not present in the
image I linked?

[...]
> To see where the packets go I'd add
>
> iptables -A FORWARD -j LOG --log-prefix "debug "
>
> as the first rule of FORWARD chain and some grep on the logfile
> afterwards.

Nonsense. You add the logging rule at the end of the chain, because you
want to know about the dropped packets. Why would you care about
accepted packets? For the given problem they just add unnecessary noise
to the logs. Adding a prefix is a good suggestion, though, as it helps
identifying the relevant log entries.

> Assuming a pretty normal config of syslog or syslog-ng the logs from
> the packet filter should be found either in /var/log/messages or
> /var/log/firewall or so,

One could use 'grep "PREFIX STRING" /var/log/*' to identify the log
file.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: IPTables port forwarding issues

Ansgar -59cobalt- Wiechers wrote:


>> iptables -A FORWARD -j LOG --log-prefix "debug "
>>
>> as the first rule of FORWARD chain and some grep on the logfile
>> afterwards.
>
> Nonsense. You add the logging rule at the end of the chain, because you
> want to know about the dropped packets.

The packets the OP looks for are not dropped. They seem to vanish. And to
check that, you need to see every packet that enters the filter and then
follow it's tracks.

> Why would you care about accepted packets?

Of course you don't need that in normal operation. But here we are talking
about 'debug mode'. Sometimes one needs that for debugging, to make that
clear I wrote '--log-prefix "debug "'

> For the given problem they just add unnecessary noise
> to the logs.

Nope, you want to hear everything in debug mode. ,)

Wolfgang

Re: IPTables port forwarding issues

Wolfgang Kueter wrote:
> Ansgar -59cobalt- Wiechers wrote:
>>> iptables -A FORWARD -j LOG --log-prefix "debug "
>>>
>>> as the first rule of FORWARD chain and some grep on the logfile
>>> afterwards.
>>
>> Nonsense. You add the logging rule at the end of the chain, because
>> you want to know about the dropped packets.
>
> The packets the OP looks for are not dropped. They seem to vanish.

Packets do not "vanish". Unless there are rules doing some funky stuff
(which isn't the case here, except for two REJECT rules that don't apply
to the packets in question) packets are either ACCEPTed or DROPed.
Period. And how would you know that the packets are not dropped? The
logging rules the OP has in place (according to what he posted) won't
match the NATed packets, so they simply won't show up in the logs.

[...]
>> Why would you care about accepted packets?
>
> Of course you don't need that in normal operation. But here we are
> talking about 'debug mode'. Sometimes one needs that for debugging, to
> make that clear I wrote '--log-prefix "debug "'
>
>> For the given problem they just add unnecessary noise to the logs.
>
> Nope, you want to hear everything in debug mode. ,)

I most certainly do not want to drown in log entries when trouble-
shooting something. I'd start with a basic ruleset (only ACCEPT rules)
and the LOG rule at the end of the chain. Either the packet is logged
when it hits the LOG rule (and is subsequently dropped), or it hits an
ACCEPT rule before and is delivered, in which case I'd suggest to start
inspecting the traffic with a sniffer, because the problem probably lies
elsewhere.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: IPTables port forwarding issues

Ansgar -59cobalt- Wiechers wrote:


>> Nope, you want to hear everything in debug mode. ,)
>
> I most certainly do not want to drown in log entries when trouble-
> shooting something.

I've trouble-shooted Linux filters more than once and sonething like

tail -f /path/to/logfile | grep debug | grep ...

has saved me from drowning most of the time. ;)

> I'd start with a basic ruleset (only ACCEPT rules)
> and the LOG rule at the end of the chain. Either the packet is logged
> when it hits the LOG rule (and is subsequently dropped), or it hits an
> ACCEPT rule before and is delivered, in which case I'd suggest to start
> inspecting the traffic with a sniffer, because the problem probably lies
> elsewhere.

The 'log-all' rule at the beginnig of a chain (or even all chains) makes
quite a good sniffer and installing such a rule takes far less time than
firing up etherreal and getting monitor port on the switch ready.

Wolfgang

Re: IPTables port forwarding issues

Wolfgang Kueter wrote:

Well, Ansgar, because it is you, I'll give an example to make things clear:

;)

> The 'log-all' rule at the beginnig of a chain (or even all chains) makes
> quite a good sniffer and installing such a rule takes far less time than
> firing up etherreal and getting monitor port on the switch ready.

Think about the following sample:

---8<---
iptables -N rule_01
iptables -N rule_02
iptables -N rule_03
iptables -N stop

iptables -A FORWARD -j LOG --log-prefix "packet entered forward chain "
# traffic to/from MACHINE_01 is handled in rule_01
iptables -A FORWARD -s $MACHINE_01 -j rule_01
iptables -A FORWARD -d $MACHINE_01 -j rule_01
iptables -A rule_01 -j LOG --log-prefix "packet entered rule_01 "
iptables -A rule_01
iptables -A rule_01
iptables -A rule_01 -j LOG --log-prefix "packet not permitted in rule_01"
iptables -A rule_01 -j stop

# traffic to/from MACHINE_02 is handled in rule_02
iptables -A FORWARD -s $MACHINE_02 -j rule_02
iptables -A FORWARD -d $MACHINE_02 -j rule_02
iptables -A rule_02 -j LOG --log-prefix "packet entered rule_02 "
iptables -A rule_02
iptables -A rule_02
iptables -A rule_02 -j LOG --log-prefix "packet not permitted in rule_02"
iptables -A rule_02 -j stop

[..]

iptables -A FORWARD -j LOG --log-prefix "packet not permitted in forward "
iptables -A FORWARD -j stop
iptables -A stop -j REJECT --reject-with icmp-host-prohibited

---8<---

If you build your ruleset according to that example you can easily follow
each packet through the filter for debugging even in a complicated setup
completely and you don't need a sniffer at all, because the sniffer is
built in ...

Wolfgang

Re: IPTables port forwarding issues

Wolfgang Kueter wrote:
> Well, Ansgar, because it is you, I'll give an example to make things
> clear:

Don't get smart with me, bub. I know pretty well how to use logging and
log-prefixes. I just don't agree that it would be easier than what I
suggested:

----8<----
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \
--to ${IPVPNMAIN}

iptables -A INPUT -I lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "dbg_nf_in drop: "

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix "dbg_nf_out drop: "

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
-j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "dbg_nf_fwd drop: "

iptables -A POSTROUTING -j SNAT -o ${WAN} --to ${EXTERNALIP}
---->8----

Either a packet is logged (in case it didn't match any ACCEPT rule), or
it is ACCEPTed and thus delivered by netfilter. In the latter case I'd
run 'tcpdump -nvvi $INTERFACE "tcp port 9023"' to see where the traffic
is going after it leaves the filter.

Maybe we can agree on something like this:

----8<----
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \
--to ${IPVPNMAIN}

iptables -A INPUT -j LOG --log-prefix "dbg_nf_in enter: "
iptables -A INPUT -I lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "dbg_nf_in drop: "

iptables -A OUTPUT -j LOG --log-prefix "dbg_nf_out enter: "
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix "dbg_nf_out drop: "

iptables -A FORWARD -j LOG --log-prefix "dbg_nf_fwd enter: "
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ${WAN} -p tcp --dport 9023 -m state --state NEW \
-j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "dbg_nf_fwd drop: "

iptables -A POSTROUTING -j SNAT -o ${WAN} --to ${EXTERNALIP}
---->8----

However, you'd still have to inspect the traffic that is not dropped.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: IPTables port forwarding issues

Ansgar -59cobalt- Wiechers wrote:

> Wolfgang Kueter wrote:
>> Well, Ansgar, because it is you, I'll give an example to make things
>> clear:
>
> Don't get smart with me, bub. I know pretty well how to use logging and
> log-prefixes.

I know.

> I just don't agree that it would be easier than what I
> suggested:

;)

> Maybe we can agree on something like this:
>
> [...]

Yes, I regard that as an acceptable compromise. ;)

best wishes
Wolfgang