FC3 problem with ip_forward / masquerade : no more DNS resolution

Pierre-Yves Berger linux at pyves.ch
Fri Nov 12 16:40:12 UTC 2004


On 11 nov. 04, at 18:27, Alexander Dalloz wrote:

> Am Do, den 11.11.2004 schrieb Pierre-Yves Berger um 18:14:
>
>> I just installed FC3 on a system I use as nat.
>> eth0 gets a dynamic address from my ISP.
>> eth1 has a static local address.
>>
>> I did the configuration as described in the NAT-HOWTO document
>> at www.netfilter.org.
>>
>> Now, from the computers on my local network, I cannot access Internet
>> using the names. I can access everything with ip numeric addresses.
>>  From the nat computer, I can access everything (names and numeric
>> addresses).
>
> This problem description normally says that the NATed hosts have no
> valid nameserver knowledge.
>
>> The computers on the local network have correct DNS entries and worked
>> correctly before I swapped my old (hardware) unstable FC2 box with a
>> newer FC3 box.
>
> To where do the DNS entries on the NATed clients point?
>
>> Pierre-Yves
>
> Alexander

resolv.conf contains the following entries :
nameserver 80.83.47.10
nameserver 80.83.47.157

These are correct for my ISP.
I can ping them from my NATed client but nslookup or dig could not 
connect.

Then, I tried to log rejected packets in iptables on the NAT system and 
got those in
/var/log/messages

Nov 11 21:30:29 gate kernel: IN=eth1 OUT=eth0 SRC=x.x.x.x 
DST=80.83.47.157 \
LEN=58 TOS=0x00 PREC=0x00 TTL=63 ID=37097 PROTO=UDP SPT=2027 \
DPT=53 LEN=38
Nov 11 21:30:29 gate kernel: IN=eth1 OUT=eth0 SRC=x.x.x.x 
DST=80.83.47.10 \
LEN=58 TOS=0x00 PREC=0x00 TTL=63 ID=37100 PROTO=UDP SPT=2030 \
DPT=53 LEN=38
with x.x.x.x being my NATed client address.

So, I added a rule in iptables that says

-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT

at the beginning of the RH-Firewall-1-INPUT chain and I have again 
access to the world :-)

Is there a better way to do this ?

I may add that this is my home network with 2 Macs and a Linux system 
and users are not
a security risk, at least not deliberately.

Pierre-Yves




More information about the fedora-list mailing list