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

Re: UDP NAT [Nat to DNS Server]



Thanks for all your help everyone.

----- Original Message -----
From: "Matthew Palmer" <mjp16@ieee.uow.edu.au>
To: "Ryan White" <ryan@itamigo.com>
Cc: <debian-firewall@lists.debian.org>
Sent: Tuesday, December 18, 2001 6:38 PM
Subject: Re: UDP NAT [Nat to DNS Server]


> On Tue, 18 Dec 2001, Ryan White wrote:
>
> > That is in fact what I am trying to do. I already tried to forward port
53
> > for both tcp and UDP but the problem is the packets are never coming
back
> > out of the NAT. TCP works fine but dns uses UDP mostly. In addition to
DNS
>
> That's odd, because I've got a line similar in my firewall config, and it
> works a treat:
>
> (apologies for wrapping)
> # DNS goes to klystron
> $FW -A PREROUTING -t nat -p tcp -d 130.130.88.183 --dport 53 -j DNAT --to
192.168.84.4:53
> $FW -A PREROUTING -t nat -p udp -d 130.130.88.183 --dport 53 -j DNAT --to
192.168.84.4:53
>
> And DNS lookups work fine (at least, INWW hasn't complained yet!).

It might be a problem with M$ DNS. I just assumed that it was a UDP problem
because the tcp connections seemed to connect fine but nslookup would not
work.
>
> As for other ports, I can't see any reason why it wouldn't work.  We've
got
> Quake aplenty going just fine behind here.
>
> > one of the departments within our network needs a "bidirectional" UDP
NAT.
>
> Define "bidirectional" in this case.  I think you just want a regular port
> forwarding NAT, where packets from the outside world get forwarded to a
> private IP, and the returning packets get munged back to real-world
values.

That is what I want. I'll turn on some logging because he says the packets
are getting there but never coming back. I'm still looking up the SNAT to
try and figure out what the difference is.

> > Here is my UDP nat attempt.
> > $IPTABLES -A PREROUTING -p udp -t nat -d pub.lic.ip.add --dport 2001 -j
> > DNAT --to 172.16.1.253:2001
>
> This should be fine.  As you can see, it's identical to mine above, in
> effect.  Perhaps you should turn on some logging and see if your logs show
> anything pertinent.
>
>
> --
> -----------------------------------------------------------------------
> #include <disclaimer.h>
> Matthew Palmer
> mjp16@ieee.uow.edu.au
>
>



Reply to: