🚀 go-pugleaf

Hi,

Since I converted my ipchains-rules to iptables, my local DNS-server
doesn't work anymore.

this is the config : 
	(local DNS-server: 192.168.102.13)
	192.168.102.0/24
	       LAN 
		|
		|
	192.168.102.5
	      Linux  (kernel 2.4.18, iptables v1.2.5)
	213.224.999.999
		|
		|
	    INTERNET
	(an internet DNS-server : 195.0.51.66)

If I use these (simplified) ipchains-firewall, everything works fine :

	#!/bin/sh
	/sbin/modprobe ipchains
	echo 1 > /proc/sys/net/ipv4/ip_forward
	/sbin/ipchains -F forward
	/sbin/ipchains -P forward DENY
	/sbin/ipchains -A forward -s 192.168.102.0/24 -j MASQ
	/sbin/ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -j DENY
	/sbin/ipchains -F input
	/sbin/ipchains -P input ACCEPT
	/sbin/ipchains -F output
	/sbin/ipchains -P output ACCEPT

As we can proof with this tcpdump-output (after a local workstation
started a 'ping www.stubru.be') : 
* on internal interface (before MASQ)
   13:36:39.697718 192.168.102.13.domain > 195.0.51.66.domain: \ 
	8292 A? www.stubru.be. (31)
   13:36:39.766156 195.0.51.66.domain > 192.168.102.13.domain: \ 
	8292* 1/0/0 A 195.0.110.51 (47)     
* or the same on external interface (after MASQ)
   13:36:39.697744 213.224.999.999.61000 > 195.0.51.66.domain: \ 
	8292 A? www.stubru.be. (31)
   13:36:39.766132 195.0.51.66.domain > 213.224.999.999.61000: \ 
	8292* 1/0/0 A 195.0.110.51 (47)
As you can see : on the external interface, the Ip-adress AND
PORT-number are translated (from domain=53 to 61000).

Then I changed the ipchains-rules to this iptables config : 
	#!/bin/sh
	EXTDEV=eth1
	echo 1 > /proc/sys/net/ipv4/ip_forward
	/sbin/iptables --flush
	/sbin/iptables -X
	/sbin/iptables -t nat -A POSTROUTING -o $EXTDEV -j MASQUERADE
	/sbin/iptables -P FORWARD ACCEPT
	/sbin/iptables -P INPUT ACCEPT
	/sbin/iptables -P OUTPUT ACCEPT
and all of a sudden, the external dns-requests of my dns-server stop
working.

As proven by this tcpdump-output (after a local workstation started a
'ping www.donna.be') : 
* on internal interface (before MASQ)
   14:02:34.808729 192.168.102.13.domain > 198.6.1.82.domain: \
	8688 A? www.donna.be. (30)
   14:02:35.804819 192.168.102.13.domain > 198.6.1.82.domain: \
	2559 A? www.donna.be. (30)
   14:02:36.897332 192.168.102.13.domain > 134.58.40.4.domain: \
	8688 A? www.donna.be. (30)
   14:02:37.808455 192.168.102.13.domain > 198.6.1.82.domain: \
	4608 A? www.donna.be. (30)
   14:02:37.899344 192.168.102.13.domain > 134.58.40.4.domain: \
	2559 A? www.donna.be. (30)
   .... these kind of messages appear a hunderd times ....
* or the same on external interface (after MASQ)
   14:02:34.808965 213.224.999.999.domain > 198.6.1.82.domain: \
	8688 A? www.donna.be. (30)
   14:02:35.804930 213.224.999.999.domain > 198.6.1.82.domain: \
	2559 A? www.donna.be. (30)
   14:02:36.897465 213.224.999.999.domain > 134.58.40.4.domain: \
	8688 A? www.donna.be. (30)
   14:02:37.808571 213.224.999.999.domain > 198.6.1.82.domain: \
	4608 A? www.donna.be. (30)
   14:02:37.899388 213.224.999.999.domain > 134.58.40.4.domain: \
	2559 A? www.donna.be. (30)
   .... these kind of messages appear a hunderd times ....
As you can see : on the external interface, the IP-address is MASQ'ed,
but the port NOT !! This is the reason why we don't get any answer
back on these requests, because our provider does block incomming
trafic for port 53. And therefor the local dns-server keeps sending
requests to the different internet dns-servers hoping it will ever get
an answer.

IN SHORT : 
Why doesn't the MASQ-module of iptables translate the portnumber when
it's MASQ'ing (and ipchains did !) ??
First I thought it wasn't doing this for DNS-request only, but taking
a closer look, it doesn't do this for any service.
So if two computers in my LAN start an http-request from their local
port 1026, my linux-router/firewall will sent them both out with the
same source-port.  I'm wondering what kind of effect this wil have !

Sorry for this rather long post, but since it's such a strange
behaviour, I thought that a detailed explanation was necessary.
Thanx in advance for your assistance,

Koen.