🚀 go-pugleaf

On Fri, 03 Jan 2003 16:17:39 GMT, nospam.koen.vdvelde@advalvas.be
(Koen Van de Velde) wrote:

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

>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.

Assuming bind is being used, has /etc/named.conf been altered? My copy
has the following comment:
         * Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;

>
>IN SHORT : 
>Why doesn't the MASQ-module of iptables translate the portnumber when
>it's MASQ'ing (and ipchains did !) ??
man iptables :
 --to-ports port[-port]
  This  specifies  a  range of source ports to use, overriding the
  default SNAT source port-selection heuristics (see above).  This
  is only valid if the rule also specifies -p tcp or -p udp.


>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 !
Not an expert, but presumably the de-masq'ing process sorts it out and
sends the reply packets back where they should go. Not sure how it
would work if both requests were going the the same destination
though.
-- 
John

On Fri, 03 Jan 2003 16:32:23 +0000, John Armstrong
<ja@ggrove.swinternet.co.uk> wrote:

Hi John,
thanks for your response

[snip again]
>
>Assuming bind is being used, has /etc/named.conf been altered? My copy
>has the following comment:
>         * Previous versions of BIND always asked
>         * questions using port 53, but BIND 8.1 uses an unprivileged
>         * port by default.
>         */
>        // query-source address * port 53;
>
it's not Bind, it's M$ ;-( (ssstt, don't tell anyone) 
but it's ok for me that (on the local network) it acts as a dns-server
and therefor sents its requests to other dns-servers FROM (and to)
port 53.

>>
>>IN SHORT : 
>>Why doesn't the MASQ-module of iptables translate the portnumber when
>>it's MASQ'ing (and ipchains did !) ??
>man iptables :
> --to-ports port[-port]
>  This  specifies  a  range of source ports to use, overriding the
>  default SNAT source port-selection heuristics (see above).  This
>  is only valid if the rule also specifies -p tcp or -p udp.
I think this one is more used for redirection. eg: incomming packets
on port 8000 on external interface of router should be redirected to
other internal machine on port 80 (then the --to-ports 80 should be
used). As described in 6.2.1 of the NAT-howto.

>>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 !
>Not an expert, but presumably the de-masq'ing process sorts it out and
>sends the reply packets back where they should go. Not sure how it
>would work if both requests were going the the same destination
>though.

I thought it would give each outgoing packet a new unique source-port
(let's say: starting from 61000). When the packets come back, it can
check this port, look it up in it's NAT-table, and forward the packet
to the original requester. As far as I know, this is how ipchains
worked.
Now it seems that iptables is doing it different, Or I did something
wrong with my configuration, Or I'm using a buggy version of iptables.

K.

Koen Van de Velde wrote:

> I thought it would give each outgoing packet a new unique source-port
> (let's say: starting from 61000). When the packets come back, it can
> check this port, look it up in it's NAT-table, and forward the packet
> to the original requester. As far as I know, this is how ipchains
> worked.
> Now it seems that iptables is doing it different, Or I did something
> wrong with my configuration, Or I'm using a buggy version of iptables.

Both ipchains and iptables only change the address, not ports - unless
you specifically configure them to do so.

Jan Pieter.

On Fri, 03 Jan 2003 17:06:20 GMT, nospam.koen.vdvelde@advalvas.be
(Koen Van de Velde) wrote:

>On Fri, 03 Jan 2003 16:32:23 +0000, John Armstrong
><ja@ggrove.swinternet.co.uk> wrote:
>

>>man iptables :
>> --to-ports port[-port]
>>  This  specifies  a  range of source ports to use, overriding the
>>  default SNAT source port-selection heuristics (see above).  This
>>  is only valid if the rule also specifies -p tcp or -p udp.
>I think this one is more used for redirection. eg: incomming packets
>on port 8000 on external interface of router should be redirected to
>other internal machine on port 80 (then the --to-ports 80 should be
>used). As described in 6.2.1 of the NAT-howto.

That would be the --to-ports option of the REDIRECT target, which
gives a range of destination ports, while the --to-ports option of
MASQUERADE gives a range of source ports.
-- 
John

On Mon, 06 Jan 2003 10:12:13 +0000, John Armstrong
<ja@ggrove.swinternet.co.uk> wrote:

>On Fri, 03 Jan 2003 17:06:20 GMT, nospam.koen.vdvelde@advalvas.be
>(Koen Van de Velde) wrote:
>
>>On Fri, 03 Jan 2003 16:32:23 +0000, John Armstrong
>><ja@ggrove.swinternet.co.uk> wrote:
>>
>
>>>man iptables :
>>> --to-ports port[-port]
>>>  This  specifies  a  range of source ports to use, overriding the
>>>  default SNAT source port-selection heuristics (see above).  This
>>>  is only valid if the rule also specifies -p tcp or -p udp.
>>I think this one is more used for redirection. eg: incomming packets
>>on port 8000 on external interface of router should be redirected to
>>other internal machine on port 80 (then the --to-ports 80 should be
>>used). As described in 6.2.1 of the NAT-howto.
>
>That would be the --to-ports option of the REDIRECT target, which
>gives a range of destination ports, while the --to-ports option of
>MASQUERADE gives a range of source ports.
>-- 
>John

Hi John,
I changed my masq-lines to  :
  /sbin/iptables -t nat -A POSTROUTING -s 192.168.102.13 -p udp \
    --sport 53 -o $EXTDEV -j MASQUERADE --to-port 61000:65095
  /sbin/iptables -A POSTROUTING -t nat -o $EXTDEV -j MASQUERADE    
and this works fine now !

thanks for your assistance,
Koen.

On Mon, 06 Jan 2003 12:02:56 GMT, nospam.koen.vdvelde@advalvas.be
(Koen Van de Velde) wrote:

>
>Hi John,
>I changed my masq-lines to  :
>  /sbin/iptables -t nat -A POSTROUTING -s 192.168.102.13 -p udp \
>    --sport 53 -o $EXTDEV -j MASQUERADE --to-port 61000:65095

You might want to add a line
  /sbin/iptables -t nat -A POSTROUTING -s 192.168.102.13 -p tcp \
    --sport 53 -o $EXTDEV -j MASQUERADE --to-port 61000:65095

As I understand it, if the dns reply is over a certain size, it goes
by tcp rather than udp, so while everything will work most of the time
without this, it will sometimes fail.

>  /sbin/iptables -A POSTROUTING -t nat -o $EXTDEV -j MASQUERADE    
>and this works fine now !
>
>thanks for your assistance,
>Koen.

-- 
John