Problems with DNAT.

Dear newsgroup.

I have a program acting as a server that I want to run on a local machine
not visible from outside my local network. I'm trying to set this up using
DNAT like so:

The server is running on 192.168.0.1 port 15621

The gateway (called upasmaster.af.op.dlr.de) has an external ip:
129.247.185.96 on eth1. The local network sits on eth0.

My client and server machines can only see the gateway, not each other.

# iptables -A FORWARD -i eth1 -p tcp --dport 15621 -j ACCEPT
# iptables -t nat -A PREROUTING -p tcp -i eth1 -d 129.247.185.96 --dport
15621 -j DNAT --to 192.168.0.1:15621

If I run
% netcat upasmaster 15621
on the client I expect to see get a status message from my server, however
nothing happens.

I tried troubleshooting but I did't get very far, so I turned to this
newsgroup. These are my findings (sorry for possible wordwrapping).



# iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 144K packets, 28M bytes)
pkts bytes target prot opt in out source
destination
3 180 DNAT tcp -- eth1 any anywhere
upasmaster.af.op.dlr.de tcp dpt:15621 to:192.168.0.1:15621

Chain POSTROUTING (policy ACCEPT 2165 packets, 189K bytes)
pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination



# iptables -L -v
Chain INPUT (policy ACCEPT 135K packets, 16M bytes)
pkts bytes target prot opt in out source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT tcp -- eth1 any anywhere anywhere
tcp dpt:15621

Chain OUTPUT (policy ACCEPT 146K packets, 93M bytes)
pkts bytes target prot opt in out source
destination



It seems to me that the PREROUTING rule is ok but that the FORWARD rule
doesn't accept packets. I have also looked with tcpdump on the gateway. I
see packets coming in on eth1, port 15621 but I don't see any outgoing
packets on eth0. This strenghtens my believe.

I don't have much networking experience. Maybe I'm overlooking something
simple, so any help is appreciated.

Also I'd like to know:
Is the FORWARD rule realy necessary? It isn't mentioned in the HOWTO, but
reading other usenet posts suggests it is.

Regards, Pepijn.

On 2005-03-03, P. Kenter <pepijn.kenter@remove_this.dlr.de> wrote:
> The server is running on 192.168.0.1 port 15621
> The gateway (called upasmaster.af.op.dlr.de) has an external ip:
> 129.247.185.96 on eth1. The local network sits on eth0.
> # iptables -A FORWARD -i eth1 -p tcp --dport 15621 -j ACCEPT

The connection is established from the external machine to the router
(gateway). So you also need to open the same port in INPUT.

Also, what port(s) are used to respond by your server? Maybe it would
be an idea to run tcpdump on the router and see what's blocked by the
firewall.

Davide

--
It might not be practical, it might not be a good idea, but it could
work. Sort of like Windows.
--berry

Davide Bianchi wrote:

> On 2005-03-03, P. Kenter <pepijn.kenter@remove_this.dlr.de> wrote:
>> The server is running on 192.168.0.1 port 15621
>> The gateway (called upasmaster.af.op.dlr.de) has an external ip:
>> 129.247.185.96 on eth1. The local network sits on eth0.
>> # iptables -A FORWARD -i eth1 -p tcp --dport 15621 -j ACCEPT
>
> The connection is established from the external machine to the router
> (gateway). So you also need to open the same port in INPUT.
>

Thanks for the quick reply. Unfortunately it didn't work.

I tried:
# iptables -A INPUT -i eth1 -p tcp --dport 15621 -j ACCEPT
# iptables -A FORWARD -i eth1 -p tcp --dport 15621 -j ACCEPT
# iptables -t nat -A PREROUTING -p tcp -i eth1 -d 129.247.185.96 --dport
15621 -j DNAT --to 192.168.0.1:15621

Both INPUT and FORWARD have 0 accepted packets.

> Also, what port(s) are used to respond by your server?

Not a fixed port (it uses accept to create one).

> Maybe it would
> be an idea to run tcpdump on the router and see what's blocked by the
> firewall.
>

Isn't this what I allready described in my first email, or do you mean
something else? Let me give a more detailed description of what I did.
Perhaps you can get more info out of it than I can.

Ran tpcdump on the gateway:
# tcpdump -i eth0 dst host 192.168.0.1

When i run 'netcat 192.168.0.1 15621' on the gateway I get a status message
like expected, and tcpdump gives the following output.

# tcpdump -i eth0 dst host 192.168.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:53:06.397508 IP upasmaster.af.op.dlr.de.50308 > upasslv1.15621: S
3828365628:3828365628(0) win 5840 <mss 1460,sackOK,timestamp 4284374966
0,nop,wscale 0>
16:53:06.397757 IP upasmaster.af.op.dlr.de.50308 > upasslv1.15621: . ack
2651219823 win 5840 <nop,nop,timestamp 4284374966 497215081>
16:53:06.414547 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1819917028: reply
ok 116
16:53:06.414877 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1836694244: reply
ok 116
16:53:06.415423 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1853471460: reply
ok 140
16:53:06.454927 IP upasmaster.af.op.dlr.de.nfs > upasslv1.789: . ack
2603377738 win 20272 <nop,nop,timestamp 4284375024 497215099>
16:53:06.476483 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1870248676: reply
ok 132
16:53:06.476711 IP upasmaster.af.op.dlr.de.nfs > upasslv1.789: . ack 117 win
20272 <nop,nop,timestamp 4284375045 497215160>
16:53:06.476755 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1887025892: reply
ok 116
16:53:06.477202 IP upasmaster.af.op.dlr.de.50308 > upasslv1.15621: . ack 91
win 5840 <nop,nop,timestamp 4284375046 497215161>
16:53:06.477278 IP upasmaster.af.op.dlr.de.50308 > upasslv1.15621: F 0:0(0)
ack 92 win 5840 <nop,nop,timestamp 4284375046 497215161>
16:53:06.494850 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1903803108: reply
ok 116
16:53:06.495211 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1920580324: reply
ok 116
16:53:06.495743 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1937357540: reply
ok 140
16:53:06.496229 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1954134756: reply
ok 132
16:53:06.496477 IP upasmaster.af.op.dlr.de.nfs > upasslv1.1970911972: reply
ok 116

However, when I run "netcat upasmaster 15621" from my client machine,
"tcpdump -i eth0 dst host 192.168.0.1" gives no output.

I can also listen to the incoming interface with tcpdump and then I get
this:
# tcpdump -i eth1 dst port 15621
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:56:41.878359 IP galilei.af.op.dlr.de.52984 >
upasmaster.af.op.dlr.de.15621: S 3572522942:3572522942(0) win 5840 <mss
1460,sackOK,timestamp 1234142950 0,nop,wscale 0>
16:56:44.877158 IP galilei.af.op.dlr.de.52984 >
upasmaster.af.op.dlr.de.15621: S 3572522942:3572522942(0) win 5840 <mss
1460,sackOK,timestamp 1234145950 0,nop,wscale 0>
....[etc.]


It looks to me that the packets are just not forwarded to the server
machine. When the server machine sends status info to a client, it also
makes a log entry. There's no entry saying status info is send to the
client, so I'm quite sure the server doesn't receive a request for it.

Regards, Pepijn.

P. Kenter wrote:

> Dear newsgroup.
>
[snip]

Solved it (with some help). Had to do two things:

First of all I had to enable port forwarding with:
% echo "1" > /proc/sys/net/ipv4/ip_forward

Secondly, my gateway wasn't realy a gateway, just a box with two network
interfaces; no routing was done. In fact on the server machine isn't even a
gateway set, so it doesn't know how to reach the client.

Therefore I also had to add my client machine to the routing table of the
server via the gateway:
server# route add $CLIENT_IP gw $GATEWAY_IP

>
> It seems to me that the PREROUTING rule is ok but that the FORWARD rule
> doesn't accept packets. I have also looked with tcpdump on the gateway. I
> see packets coming in on eth1, port 15621 but I don't see any outgoing
> packets on eth0. This strenghtens my believe.
>

This was because port forwarding wasn't turned on.

> I don't have much networking experience. Maybe I'm overlooking something
> simple, so any help is appreciated.
>
> Also I'd like to know:
> Is the FORWARD rule realy necessary? It isn't mentioned in the HOWTO, but
> reading other usenet posts suggests it is.
>

No, at least if there are no other rules that drop packets.

Pepijn.