[4188] in RedHat Linux List
Re: masq/dns help (was Re: Alternative to IP Masquerade?)
daemon@ATHENA.MIT.EDU (James Youngman)
Wed Nov 13 06:59:14 1996
To: redhat-list@redhat.com
From: JYoungman@vggas.com (James Youngman)
Date: 13 Nov 1996 11:57:07 GMT
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
In article <56auo5$fmu@halon.vggas.com>, dmintz@csgsco1.prcrsi.com says...
>To test whether DNS is working, I have been using nslookup on the internal
>DNS machine which has a forwarder reference pointing to my external DNS
>machine. When I type server 199.201.151.1 (which is my external dns server)
>it can't reach through the firewall. Also, I don't see it trying via
>tcpdump either.
Do you mean that if you run tcpdump on the DNS machine you can't see its
outgoing packets (yes => bad conf. on that machine), or that you can't seet the
packets on the firewall? (Did you specify the right interface with the -i
option?) If so, check your fw. input rules.
Does DNS work from the firewall to the external DNS?
>I have been trying to use the following commands: ( I will only list the
>one's pertaining to DNS)
s/one's/ones/
>
> IPFW="/sbin/ipfwadm"
> echo "Add forwarding rules for nameserver"
> $IPFW -F -a masquerade -P udp -V 192.168.1.4 -S 192.168.1.1 53 -D
>0.0.0.0/0 53
> echo "Add input rule for nameserver -> me"
> $IPFW -I -a accept -P udp -S 192.168.1.1 53 -D 192.168.1.4
No! The source port from the DNS server will be ephemeral, not 53.
Also surely the destination address shoul be that of the external DNS
server, not that of the firewall.
> echo "Add input rule for Internet -> nameserver (masqueraded)"
> $IPFW -I -a accept -P udp -S 0.0.0.0/0 53 -D 199.201.151.4
The source port is not required (AFAIK) to be 53, however perhaps you should
specify the destination port as 53 here.
> echo "Add input rule for nameserver -> Internet (will masquerade)"
> $IPFW -I -a accept -P udp -S 192.168.1.1 53 -D 0.0.0.0/0 53
Again the source port may be ephemeral (i.e., not 53)..
>echo "Add output rule for me -> nameserver"
> $IPFW -O -a accept -P udp -S 192.168.1.4 -D 192.168.1.1 53
If the idea here is that the fw be able to forward packets to the
nameserver, the nameserver will not be requiring an answer to port 53,
neccessarily.
> echo "Add output rule for nameserver -> Internet"
> $IPFW -O -a accept -P udp -S 199.201.151.4 -D 0.0.0.0/0 53
> echo "Add output rule for Internet -> nameserver (masqueraded)"
> $IPFW -O -a accept -P udp -S 0.0.0.0/0 53 -D 192.168.1.1 53
The port might be ephemeral. Particularly for nslookup (since the name server
itself will already be bound to port 53).
>IP firewall forward rules, default policy: deny
>type prot source destination ports
>acc/m udp int-dns anywhere domain -> domain
>acc/m tcp internal-net/24 anywhere any -> any
>IP firewall input rules, default policy: deny
>type prot source destination ports
>acc udp int-dns firewall_internal domain -> any
>acc udp anywhere firewall_external domain -> any
>acc udp int-dns anywhere domain -> domain
>acc tcp anywhere firewall_external any -> smtp
>acc tcp anywhere firewall_external ftp-data -> 1024:65535
>acc tcp anywhere firewall_external any -> any
>acc tcp internal-net/24 anywhere any -> any
>IP firewall output rules, default policy: deny
>type prot source destination ports
>acc udp firewall_internal int-dns any -> domain
>acc udp firewall_external anywhere any -> domain
>acc udp anywhere int-dns domain -> domain
>acc tcp firewall_external anywhere any -> any
>acc tcp anywhere internal-net/24 ftp-data -> 1024:65535
>acc tcp anywhere internal-net/24 any -> any
>IP accounting rules
>IP masquerading entries
>
>Btw, I am using Redhat Linux 3.03 (Picasso) upgraded to kernel 2.0.14.
Note that RH don't support that config; you are better off upgrading to Red Hat
40 (which does use a 2.0 kernel and is supported).
>Just wondering if you might see something obvious...
My general advice is to change the policy temporarily from deny to accept
and set it up so it works then (i.e. get the DNS system working to make sure
that that part of the configuration is set up OK) and then set the defauilt
policy back to deny and get it working again. There's no point trying to
debug two separate things at the time, both of which have to be just right.
--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
________________________________________________________________________
http://www.redhat.com/RedHat-FAQ http://www.redhat.com/RedHat-Errata
http://www.redhat.com/RedHat-Tips http://www.redhat.com/mailing-lists
------------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe redhat-list-request@redhat.com < /dev/null
