[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: desperate! can't get port forwarding to work on debian testing 2.6.15


Mike Garey a écrit :
I've just set up a new machine running debian testing with a 2.6.15
kernel and I'm having some real trouble getting port forwarding to
work..  I've got two NIC's and I'm using the following simple firewall

EXTIF="external"             #used ifrename to rename interface (see
below for details)

echo "   Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward

$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 8090 -m state

You can remove ESTABLISHED and RELATED from this rule. They're dealt with by a general rule below. Instead you can add a destination address match '-d $PORTFWIP' so your gateway won't forward port 8090 to only this host on the internal side. Think that with proper routing a host on the external side may be able to send to your gateway packets with an internal destination address. Such packets would not be affected by the following DNAT rule and accepted by the above FORWARD rule.

$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 8090 -m state --state NEW,ESTABLISHED,RELATED -j DNAT --to $PORTFWIP:8090

You can remove the 'state' match : nat chains don't see ESTABLISHED nor RELATED packets.

$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state

echo "   Enabling SNAT (MASQUERADE) functionality on $EXTIF"

If $EXTIF has a fixed address, you can use "SNAT --to $EXTIP" instead of MASQUERADE, it will take a little less CPU resources.


I've been trying to telnet from an external machine to, in hopes that it'll be forwarded to, but no matter what I do, I can't get the
forwarding to work.  If I run tcpdump on the gateway machine
( by using:

sudo tcpdump -i internal tcp port 8090 and src or dst net -vv

And then try to telnet to port 8090 from another machine on the
internet, I get the following:

00:29:14.353035 IP (tos 0x0, ttl  54, id 18514, offset 0, flags [DF],
proto: TCP (6), length: 60) wilshire.dreamhost.com.55787 > S, cksum 0x1463 (correct),
2921922032:2921922032(0) win 65535 <mss 1400,nop,wscale
0,nop,nop,timestamp 1065216778 0>
[and so on]

SYN packets come out from the internal interface with the correct destination address, so your port forwarding (DNAT and FORWARD) works.

and then in /var/log/kern.log, I see the following:

Apr 12 23:38:53 asterisk kernel: IN=external OUT=internal
SRC= DST= LEN=44 TOS=0x00 PREC=0x00 TTL=54
ID=14381 DF PROTO=TCP SPT=55698 DPT=8090 WINDOW=65535 RES=0x00 SYN

In a way, it's consistent with the iptables ruleset and the tcpdump output, as the destination address is correct. But the presence in the kernel log means that the packet was not accepted by the first FORWARD rule, and that's not consistent. The times of the tcpdump output and kernel log don't match, maybe it was a previous attempt with a different ruleset ?

if I then run tcpdump on the internal machine ( by using:

sudo tcpdump  -vv -i em0 port 8090  (FreeBSD box)

Too bad you monitored only TCP/8090 traffic. ICMP traffic, with signals errors, would have been interesting too.

I get:

00:32:30.014144 IP (tos 0x0, ttl  47, id 19712, offset 0, flags [DF],
proto: TCP (6), length: 60) wilshire.dreamhost.com.47191 > S, cksum 0xb12b (correct),
4194765628:4194765628(0) win 5840 <mss 1400,sackOK,timestamp 21967827
0,nop,wscale 0>

so it looks like packets are actually being forwarded from the
external machine ( to the internal machine

Indeed. So the port forwarding works. But there seems to be no reply from the destination host.

for some reason, forwarding just refuses to work properly.

No, it works.

Also, if I
try to telnet from the gateway machine directly to,
it works perfectly..

Maybe your BSD box has no default route to the NAT gateway, or it has a firewall filtering out packets originated from outside the internal network.

included below is the output from "iptables -t nat -n -L"

Without the "-v" option, it won't show the input and/or output interfaces. IMHO the ouput of 'iptables-save' is easier to read.

and iptables -n -L shows:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)

Ahem... Default policy ACCEPT ? So what's the use of all those rules ?

Reply to: