On Thu, May 23, 2002 at 05:53:51PM -0600, Marc Aurele La France wrote:
> On Thu, 23 May 2002, Ramin Alidousti wrote:
>
> > On Thu, May 23, 2002 at 02:56:58PM -0600, Marc Aurele La France wrote:
>
> > > > Best of luck with the request, and I'm fascinated to know why this is
> > > > considered a sensible way to run UDP....
>
> > > One can easily run DNS this way, for load balancing, etc.
>
> > Can you come up with a scenario for this DNS case? Do you mean that
> > I send a DNS query to A and B would give me the answer?
>
> Yes. A is a NAT box that load balances (but doesn't hide) B, C, etc. So,
What do you mean by a NAT box that does not hide? Does it NAT or not?
If it NATs then it hides!!
> the reply to your request to A could come from either one of B, C, etc.
> And A can be something as small as a 386 because kernel-level NAT'ting
What do you mean by "kernel-level NAT'ing"? I thought you said that A
doesn't hide B or C, two sentences ago!!
> doesn't need a lot of ummph. We've tried a similar thing with SAMBA a
> few years ago, although SAMBA also involves TCP on a more regular basis,
> making things a little messier. This is handy when you're waiting for
> mucky-mucks to decide on the funding for a bigger server.
Have no experience with SAMBA... But if it uses TCP how do you do what
you're asking here for UDP. And you just call it a little messier. It
simply doen't work with TCP...
> > But, anyway, If you do SNAT for the outgoing UDP packets, what prevents
> > you to do DNAT for the _unrelated_ incoming UDP packets? Or maybe I don't
> > understand you question well?
>
> That would generate a lot of false positives and negatives. By INPUT
> time, I don't see how I can determine whether the packet wasn't de-masq'ed
> simply because its source addr/port wasn't what the outgoing packet said
> it would be. Neither can I tell if the target port was masq'ed in the
> first place (this also true of a PRE-ROUTING rule). By then, it's too
> late anyway because the routing decision's already been made. No, this
> needs be done during de-masq'ing, part of PRE_ROUTING.
I'm still not getting this.
If you have the IP and port of your internal (UDP) servers (yes, this only
works for predetermined port numbers) then you can do:
$IPT -t nat -A PREROUTING -i <internal interface> \
-p udp -d <external ip> --dport <server port> \
-j DNAT --to <internal IP>
But, if you mean that the internal host runs a client and sends a UDP to
IP1:PORT1, then yes, you cannot have a reply back from IP2:PORT2 to that
client, as you don't know the port of the client.
I think that you're better off correcting the behavior of the remote end
than openning up such a hole in your firewall.
Ramin
> Marc.
>
> +----------------------------------+-----------------------------------+
> | Marc Aurele La France | work: 1-780-492-9310 |
> | Computing and Network Services | fax: 1-780-492-1729 |
> | 352 General Services Building | email: [EMAIL PROTECTED] |
> | University of Alberta +-----------------------------------+
> | Edmonton, Alberta | |
> | T6G 2H1 | Standard disclaimers apply |
> | CANADA | |
> +----------------------------------+-----------------------------------+
> XFree86 Core Team member. ATI driver and X server internals.
>
