Re: desperate! can't get port forwarding to work on debian testing 2.6.15
Hello,
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
script:
EXTIF="external" #used ifrename to rename interface (see
below for details)
INTIF="internal"
EXTIP="216.125.24.45"
PORTFWIP="192.168.1.120"
IPTABLES=/sbin/iptables
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 8090 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT
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
ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG
echo " Enabling SNAT (MASQUERADE) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
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
216.125.24.45:8090, in hopes that it'll be forwarded to
192.168.1.120:8090, but no matter what I do, I can't get the
forwarding to work. If I run tcpdump on the gateway machine
(216.125.24.45) by using:
sudo tcpdump -i internal tcp port 8090 and src or dst net 192.168.1.120 -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 >
192.168.1.120.8090: 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=205.196.222.10 DST=192.168.1.120 LEN=44 TOS=0x00 PREC=0x00 TTL=54
ID=14381 DF PROTO=TCP SPT=55698 DPT=8090 WINDOW=65535 RES=0x00 SYN
URGP=0
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 (192.168.1.120) 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 >
192.168.1.120.8090: 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 (216.125.24.45) to the internal machine
(192.168.1.120),
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 192.168.1.120:8090,
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: