Discussion:
What can make DNS lookups slow?
(too old to reply)
Chris Evans
2005-01-10 20:12:48 UTC
Permalink
Situation I have with a firewall machine facing an ADSL router is that
DNS lookups are slow: several seconds. However, other TCP/IP traffic,
principally HTTP, seems fast. The slow lookups are true whether direct off
that machine or for other machines that lookup through it (either just
NAT transfer or if they look to BIND9 running on the machine).
Generally another machine being proxy ARP presented to the same router
through the same ethernet card seems to do lookups much faster.

I am sure the clue is in the better speed of the proxy ARP lookup
transfer but damned if I can see what the answer is. HELP hugely
appreciated as the slow lookups are driving me mad!

TIA,

Chris
Daniel L. Miller
2005-01-12 17:30:00 UTC
Permalink
If I were to guess - it's a DNS misconfiguration problem, not an
iptables problem.

Easy stuff first - what's in your /etc/resolv.conf?
Are you running any DNS servers on your firewall machine? If so, what?
You need to share a bit more information.
Post by Chris Evans
Situation I have with a firewall machine facing an ADSL router is that
DNS lookups are slow: several seconds. However, other TCP/IP traffic,
principally HTTP, seems fast. The slow lookups are true whether direct off
that machine or for other machines that lookup through it (either just
NAT transfer or if they look to BIND9 running on the machine).
Generally another machine being proxy ARP presented to the same router
through the same ethernet card seems to do lookups much faster.
I am sure the clue is in the better speed of the proxy ARP lookup
transfer but damned if I can see what the answer is. HELP hugely
appreciated as the slow lookups are driving me mad!
TIA,
Chris
--
Daniel
Chris Evans
2005-01-12 18:41:50 UTC
Permalink
Wednesday, January 12, 2005, 5:30:00 PM, Daniel Miller wrote:

DLM> If I were to guess - it's a DNS misconfiguration problem, not an
DLM> iptables problem.

DLM> Easy stuff first - what's in your /etc/resolv.conf?
DLM> Are you running any DNS servers on your firewall machine? If so, what?
DLM> You need to share a bit more information.
Thanks Daniel. I did try that earlier and got no responses. Hugely
appreciate your input. I have same problem with and without bind9
running on the machine. So with /etc/resolv.conf as:
cat resolv.conf
search psyctc.org
nameserver 127.0.0.1
nameserver 213.120.62.97
nameserver 213.120.62.98
nameserver 213.120.62.99
nameserver 213.120.62.100
nameserver 213.120.62.101
nameserver 213.120.62.102
nameserver 213.120.62.103
nameserver 213.120.62.104
and bind9 running I get:
time nslookup -sil www.sghms.ac.uk
Server: 213.120.62.101
Address: 213.120.62.101#53

Non-authoritative answer:
Name: www.sghms.ac.uk
Address: 194.82.51.10

real 0m5.348s
user 0m0.010s
sys 0m0.000s

If it stop bind and take 127.0.0.1 out of resolv.conf no change:
time nslookup -sil www.sghms.ac.uk
Server: 213.120.62.101
Address: 213.120.62.101#53

Non-authoritative answer:
Name: www.sghms.ac.uk
Address: 194.82.51.10

real 0m4.247s
user 0m0.010s
sys 0m0.000s

Utterly bizarrely to my mind, the server machine is fast in its
lookups. The hardware is slower and has essentially same resolv.conf:
search psyctc.org
#nameserver 217.34.100.197
nameserver 213.120.62.97
nameserver 213.120.62.98
nameserver 213.120.62.99
nameserver 213.120.62.100
nameserver 213.120.62.101
nameserver 213.120.62.102
nameserver 213.120.62.103
nameserver 213.120.62.104

That machine doesn't run bind9, but is served through the firewall
machine by proxy arp is fast:

time nslookup -sil www.sghms.ac.uk
Server: 213.120.62.97
Address: 213.120.62.97#53

Non-authoritative answer:
Name: www.sghms.ac.uk
Address: 194.82.51.10

real 0m0.214s
user 0m0.140s
sys 0m0.040s

Any thoughts?

TIA,

Chris
Daniel L. Miller
2005-01-13 02:06:40 UTC
Permalink
Post by Chris Evans
DLM> If I were to guess - it's a DNS misconfiguration problem, not an
DLM> iptables problem.
DLM> Easy stuff first - what's in your /etc/resolv.conf?
DLM> Are you running any DNS servers on your firewall machine? If so, what?
DLM> You need to share a bit more information.
Thanks Daniel. I did try that earlier and got no responses. Hugely
appreciate your input. I have same problem with and without bind9
cat resolv.conf
search psyctc.org
nameserver 127.0.0.1
nameserver 213.120.62.97
nameserver 213.120.62.98
nameserver 213.120.62.99
nameserver 213.120.62.100
nameserver 213.120.62.101
nameserver 213.120.62.102
nameserver 213.120.62.103
nameserver 213.120.62.104
Wowser! How many %$#@&ing DNS servers do you need?!

I dunno how up you are on DNS theory - let me lay some background, and
if I screw up I'm certain someone else will pounce on me (gently please,
I bruise easily).

Each computer that requires domain name resolution requires a list of
one or more servers (that's your resolv.conf). Now, contrary to some
people's belief, the resolver does NOT go through a list of servers
looking for a valid response. Instead, it starts at entry #1 and tries
for resolution. As long as that server responds - that counts as a
successful resolution. "No such host" is a valid result - which means
that's the end of your workstation trying to resolve www.abc123dontask.com.

The idea for multiple entries is to provide redundancy and backups - not
multiple choices. And normally two is sufficient - unless you have
multiple physical internet connections served from different providers
and want to backup accordingly.

Each entry in resolv.conf should be functionally identical - because
that's how your computer's resolver considers them.

With this in mind - let's consider running your own DNS service for your
local LAN - and providing access to the Internet.

Let's say you have your own DNS server that is authoritative for your
LAN - located at 192.168.0.1. This server has a list of all your local
hosts - and that's ALL it knows about!

Now, in your workstation's resolv.conf, you list 192.168.0.1, along with
your service provider's primary/secondary servers. And then you act
surprised when you can find your local workstations - but not the
Internet. Or you reverse the order of entries in the resolv.conf - and
now you can find any Internet host, but not your LAN hosts!

The missing piece here is a caching DNS server. Here is where you start
specifying multiple servers. In the setup for the caching DNS server -
you list each domain, along with the associated authoritative DNS
servers. In the simple case of a single internal LAN, and the
Internet, you would list your internal domain along with its associated
servers, and then specify your service provider's servers for the
default/global/everything else (whatever your server uses).

Now you have a single source of DNS for your LAN - that when queried,
can return an answer for both your LAN and the Internet. If you
need/want a backup - then you need a backup cache, that again points to
both a source of internal DNS and to a service provider's DNS.

So now, every workstation, and server - including the firewall, should
have the following extensive resolv.conf:

domain mylocal.domain
server 192.168.0.1

and that's it!


I use djbdns for my dns servers - but if you need further help setting
up Bind9 ask anyway.

--
Daniel
John Hasler
2005-01-13 02:21:59 UTC
Permalink
Post by Chris Evans
Thanks Daniel. I did try that earlier and got no responses. Hugely
appreciate your input. I have same problem with and without bind9
cat resolv.conf
search psyctc.org
nameserver 127.0.0.1
nameserver 213.120.62.97
nameserver 213.120.62.98
nameserver 213.120.62.99
nameserver 213.120.62.100
nameserver 213.120.62.101
nameserver 213.120.62.102
nameserver 213.120.62.103
nameserver 213.120.62.104
Up to MAXNS (currently 3) name servers may be listed, one per keyword.
^^^^^^^^^^^

Thus most of your entries do nothing. You also almost certainly don't need
the 'search' line.
--
John Hasler
Chris Evans
2005-01-13 09:35:05 UTC
Permalink
JH> Up to MAXNS (currently 3) name servers may be listed, one per keyword.
JH> ^^^^^^^^^^^

JH> Thus most of your entries do nothing. You also almost certainly don't need
JH> the 'search' line.
OK. Thanks for pointing that out. I've pruned to just two servers
(213.120.62.97 and 98) -- no change in the problem. Any other
thoughts?

Many thanks,

Chris
Alan Chandler
2005-01-13 22:19:51 UTC
Permalink
Post by Chris Evans
JH> Up to MAXNS (currently 3) name servers may be listed, one per keyword.
JH> ^^^^^^^^^^^
JH> Thus most of your entries do nothing. You also almost certainly don't
need JH> the 'search' line.
OK. Thanks for pointing that out. I've pruned to just two servers
(213.120.62.97 and 98) -- no change in the problem. Any other
thoughts?
Can your DNS server do the reverse lookup properly (ie find both the name from
the ip address and the ip address from the name).

I think that is sometimes the reason for slow response. (I once had an old
linux book (it came with red hat 5.0 - to give you an idea of how old it is)
which explained why this was the case. I can't remember the reason now).
--
Alan Chandler
***@chandlerfamily.org.uk
First they ignore you, then they laugh at you,
then they fight you, then you win. --Gandhi
Chris Evans
2005-01-14 08:27:43 UTC
Permalink
Thursday, January 13, 2005, 10:19:51 PM, Alan wrote:

AC> Can your DNS server do the reverse lookup properly (ie find both the name from
AC> the ip address and the ip address from the name).

Lookups work but as slow as forward lookups. Thanks.

Chris
Alvin Oga
2005-01-13 03:03:17 UTC
Permalink
Post by Daniel L. Miller
Post by Chris Evans
cat resolv.conf
search psyctc.org
nameserver 127.0.0.1
unless the machine is running dns ( named, bind )...
127.0.0.1 should be removed
Post by Daniel L. Miller
Post by Chris Evans
nameserver 213.120.62.97
nameserver 213.120.62.98
nameserver 213.120.62.99
nameserver 213.120.62.100
nameserver 213.120.62.101
nameserver 213.120.62.102
nameserver 213.120.62.103
nameserver 213.120.62.104
if one of those is also your gateway, use it ...
say your gateway is 213.120.62.100
and remove the rest of um

each of those should be running named or bind, and if not,
remove it
- you only need 1 or 2 or 3 of um

the list should be the same as the dns servers listed for psyctc.org
Name Server:NS0.INTERCITYUK.COM ( 195.82.119.192 )
Name Server:NS0.BLACKCATNETWORKS.CO.UK 193.201.200.34
Name Server:NS1.BLACKCATNETWORKS.CO.UK 69.55.225.40

- so remove all of yoru dns server at 213.*
unless it is your local dns server for your machine
in your lan

- sounds like oyu need to either setup a dns server
for your internal lan ... ( if you have one )

c ya
alvin
Post by Daniel L. Miller
Each computer that requires domain name resolution requires a list of
one or more servers (that's your resolv.conf).
or the dumb way is to use /etc/host files and list what you need
in the silly file ( which should be removed when there is more than
one machine ... you dont want to update /etc/hosts on each server
Post by Daniel L. Miller
Now, contrary to some
people's belief, the resolver does NOT go through a list of servers
looking for a valid response. Instead, it starts at entry #1 and tries
for resolution. As long as that server responds - that counts as a
successful resolution. "No such host" is a valid result - which means
that's the end of your workstation trying to resolve www.abc123dontask.com.
yup
Post by Daniel L. Miller
Let's say you have your own DNS server that is authoritative for your
LAN - located at 192.168.0.1. This server has a list of all your local
hosts - and that's ALL it knows about!
and it cn also know about how to find a gateway to the other networks
Post by Daniel L. Miller
Now, in your workstation's resolv.conf, you list 192.168.0.1, along with
your service provider's primary/secondary servers.
you do NOT need to use your isp server .. if you run your own dns
Post by Daniel L. Miller
Now you have a single source of DNS for your LAN - that when queried,
can return an answer for both your LAN and the Internet.
that's the right way
and a backup that automatically copies its files from the "master"

If you
Post by Daniel L. Miller
need/want a backup - then you need a backup cache, that again points to
both a source of internal DNS and to a service provider's DNS.
isp is OUT of the picture and is not required if dns is
properly setup for your domain
Post by Daniel L. Miller
So now, every workstation, and server - including the firewall, should
domain mylocal.domain
server 192.168.0.1
# one more, just in case dns dies on 192.168.0.1
server w.x.y.z

c ya
alvin
Daniel L. Miller
2005-01-13 22:31:29 UTC
Permalink
Post by Alvin Oga
Post by Daniel L. Miller
Now, in your workstation's resolv.conf, you list 192.168.0.1, along with
your service provider's primary/secondary servers.
you do NOT need to use your isp server .. if you run your own dns
That depends. I assume by "run your own DNS" you mean to setup a local
DNS server that performs its own root lookups. If that is in fact what
you meant - I don't see the benefit unless your ISP has a really
messed-up DNS server. Typically (again, I'm assuming - you know what
that means) the closest Internet DNS servers outside of your LAN are
going to be your ISP's - and unless you have real bonehead for an ISP,
those servers are reasonably well configured for the root servers and
caching operation. So contacting the Internet root servers directly
means increased communications distance - as well as increased load for
servers that aren't intended to be contacted by umpteen million small
businesses.

Since I haven't tried it yet myself I can't offer much else - though I'd
like to hear about comparisons between a well-run ISP's DNS servers and
using your own gateway server to contact the root servers directly.
Post by Alvin Oga
isp is OUT of the picture and is not required if dns is
properly setup for your domain
Again, in my very unauthoritative opinion - it depends.

--
Daniel
Chris Evans
2005-01-13 09:33:16 UTC
Permalink
Thursday, January 13, 2005, 2:06:40 AM, Daniel wrote:

DLM> Chris Evans wrote:

DLM> Wowser! How many %$#@&ing DNS servers do you need?!
I was going on advice (not Linux savvy advice) from my ISP. I've
pruned to two lines only (the first two servers). No change in the
problem.

DLM> I dunno how up you are on DNS theory - let me lay some background, and
DLM> if I screw up I'm certain someone else will pounce on me (gently please,
DLM> I bruise easily).
... lot snipped which was good to hear endorsed but did fit
my limited knowledge.

DLM> I use djbdns for my dns servers - but if you need further help setting
DLM> up Bind9 ask anyway.

I have tried running with and without Bind9 and it doesn't change the
slowness.

Any more thoughts? Are there ways of looking at TCP/IP traffic in a
way that might pinpoint the lookups and help me?

Many thanks,

Chris
Daniel L. Miller
2005-01-13 17:51:59 UTC
Permalink
Let's back up a sec. On your firewall host - which I am assuming is
directly connected to your Internet service - if the only items you have
in your resolv.conf are your domain line and your isp's two DNS servers,
is the lookup speed still poor?

Daniel
Daniel L. Miller
2005-01-13 18:03:38 UTC
Permalink
Post by Daniel L. Miller
Let's back up a sec. On your firewall host - which I am assuming is
directly connected to your Internet service - if the only items you
have in your resolv.conf are your domain line and your isp's two DNS
servers, is the lookup speed still poor?
Next question - paste the output of the following command from the firewall:

route -n

--
Daniel
Chris Evans
2005-01-14 08:24:34 UTC
Permalink
Post by Daniel L. Miller
Let's back up a sec. On your firewall host - which I am assuming is
directly connected to your Internet service - if the only items you
have in your resolv.conf are your domain line and your isp's two DNS
servers, is the lookup speed still poor?
yes

resolv.conf:
nameserver 213.120.62.97
nameserver 213.120.62.98

lookup time 6.6 secs

DLM> Next question - paste the output of the following command from the firewall:

DLM> route -n

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0

Hope this helps and continuing thanks.

Chris
Alvin Oga
2005-01-14 09:08:37 UTC
Permalink
hi ya chrsi
Post by Chris Evans
nameserver 213.120.62.97
nameserver 213.120.62.98
i assume your gateway 217.34.100.198 can ping the above 2 ip#
Post by Chris Evans
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
the above might be bad... to have those ip# going to 2 different ethernets
Post by Chris Evans
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
good since its the "2.0" network
Post by Chris Evans
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
good since its the "1.0" network
Post by Chris Evans
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
good cause eth0 is the way to get out to the world ??

so anything on eth2 ( 192.168.2.xx ) will have occasional "slow problems"
( aka timeout )

but everything on eth1 ( 192.168.1.x ) seems fine ??

c ya
alvin
Chris Evans
2005-01-14 10:11:40 UTC
Permalink
Friday, January 14, 2005, 9:08:37 AM, Alvin wrote:

AO> hi ya chrsi
Hi ya Alvin: huge thanks for persevering in helping me!
I've changed the order of your questions in my responses as I think it
may help us.
Post by Chris Evans
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
AO> the above might be bad... to have those ip# going to 2 different ethernets
OK, I agree that feels odd. I've always had this in
/etc/networks/interfaces (I've pruned comments and blank lines):
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 217.34.100.197
netmask 255.255.255.248
network 217.34.100.192
broadcast 217.34.100.199
gateway 217.34.100.198
auto eth1
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
auto eth2
iface eth2 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255

The eth0 was created during the original debian install and the
gateway is from the information that BT gave me. eth1 is the local
area network which is DNAT served through the server by iptables set
by shorewall 1.2, eth2 is the interface to the server machine
www.psyctc.org, 217.34.100.194 which is served by proxy arp iptables
rules set by shorewall.
Post by Chris Evans
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
AO> good since its the "2.0" network
Yes, and lookups through this interface, from the slow server in the
dmz, seem generally to be fast.
Post by Chris Evans
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
AO> good since its the "1.0" network
on which the damn windoze machines that I and wife have to use for all
our work sit. Both lookup slowly but otherwise seem fine.
Post by Chris Evans
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
AO> good cause eth0 is the way to get out to the world ??
Correct.

AO> so anything on eth2 ( 192.168.2.xx ) will have occasional "slow problems"
AO> ( aka timeout )
AO> but everything on eth1 ( 192.168.1.x ) seems fine ??
No, precisely the reverse.

OK. I'm sure you're onto something there but damned if I understand
it. With that in mind, back to the question you'd asked earlier....
Post by Chris Evans
nameserver 213.120.62.97
nameserver 213.120.62.98
AO> i assume your gateway 217.34.100.198 can ping the above 2 ip#
That gateway, 217.34.100.198 is a dumb router box. I can ping it but
not get into it to ping from it.

Stepping back one. I can't ping almost anything beyond it from either
the firewall machine or the dmz server (I get 100% packet loss) but I
can get to just any www server beyond it for http or the like so I assume
that BT (my ISP) have rules set to dump ping packets. I can traceroute
to those addresses from the dmz but not from the firewall (from the
firewall I get "traceroute: sendto: Operation not permitted" so I
assume I've got something that traceroute needs blocked in my
shorewall settings. The syslog message that appears to relate to that
is:
all2all:DROP:IN= OUT=eth0 SRC=217.34.100.197 DST=213.120.62.97 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=61933 PROTO=UDP SPT=61932 DPT=33435 LEN=18


I do definitely get lookups from those DNS servers from that machine
but not reliably, they are often timing out today. I think the route
is there but not reliably from the firewall machine directly (nor the
192.168.1.0 network through it by DNAT) but seems to be always there
and fast by proxy arp through the firewall from the 192.168.2.0
network. To me that seems very weird and probably diagnostic if I
only knew enough about how iptables DNAT and proxy arp work.

Thanks: any other thoughts or any of this help in any way?

Chris
Alvin Oga
2005-01-14 12:34:07 UTC
Permalink
hi ya chris

On Fri, 14 Jan 2005, Chris Evans wrote:

easiest way to solve the problem ( temporarily )

a) disable your firewall .. make it pass everything in and pass everything
out
- if that works .. than start figure out the firewall rules

b) i suspect removing the fw will not help, you will need to make sure
all machines have the same "gateway" to the outside

( what used to be the firewall )
the firewll in turn taks tot he ouside world

- use a simple 3-line masquerade firewall ( ipchains or iptables )


- the "firewall" should probably be running a dns or
/etc/hosts of all the ip# of all the machines
and that file copied to all machines
if you dont want to configure a dns for your local domain

c ya
alvin
Post by Chris Evans
AO> hi ya chrsi
Hi ya Alvin: huge thanks for persevering in helping me!
I've changed the order of your questions in my responses as I think it
may help us.
Post by Chris Evans
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
AO> the above might be bad... to have those ip# going to 2 different ethernets
OK, I agree that feels odd. I've always had this in
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 217.34.100.197
netmask 255.255.255.248
network 217.34.100.192
broadcast 217.34.100.199
gateway 217.34.100.198
auto eth1
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
auto eth2
iface eth2 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
The eth0 was created during the original debian install and the
gateway is from the information that BT gave me. eth1 is the local
area network which is DNAT served through the server by iptables set
by shorewall 1.2, eth2 is the interface to the server machine
www.psyctc.org, 217.34.100.194 which is served by proxy arp iptables
rules set by shorewall.
Post by Chris Evans
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
AO> good since its the "2.0" network
Yes, and lookups through this interface, from the slow server in the
dmz, seem generally to be fast.
Post by Chris Evans
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
AO> good since its the "1.0" network
on which the damn windoze machines that I and wife have to use for all
our work sit. Both lookup slowly but otherwise seem fine.
Post by Chris Evans
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
AO> good cause eth0 is the way to get out to the world ??
Correct.
AO> so anything on eth2 ( 192.168.2.xx ) will have occasional "slow problems"
AO> ( aka timeout )
AO> but everything on eth1 ( 192.168.1.x ) seems fine ??
No, precisely the reverse.
OK. I'm sure you're onto something there but damned if I understand
it. With that in mind, back to the question you'd asked earlier....
Post by Chris Evans
nameserver 213.120.62.97
nameserver 213.120.62.98
AO> i assume your gateway 217.34.100.198 can ping the above 2 ip#
That gateway, 217.34.100.198 is a dumb router box. I can ping it but
not get into it to ping from it.
Stepping back one. I can't ping almost anything beyond it from either
the firewall machine or the dmz server (I get 100% packet loss) but I
can get to just any www server beyond it for http or the like so I assume
that BT (my ISP) have rules set to dump ping packets. I can traceroute
to those addresses from the dmz but not from the firewall (from the
firewall I get "traceroute: sendto: Operation not permitted" so I
assume I've got something that traceroute needs blocked in my
shorewall settings. The syslog message that appears to relate to that
all2all:DROP:IN= OUT=eth0 SRC=217.34.100.197 DST=213.120.62.97 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=61933 PROTO=UDP SPT=61932 DPT=33435 LEN=18
I do definitely get lookups from those DNS servers from that machine
but not reliably, they are often timing out today. I think the route
is there but not reliably from the firewall machine directly (nor the
192.168.1.0 network through it by DNAT) but seems to be always there
and fast by proxy arp through the firewall from the 192.168.2.0
network. To me that seems very weird and probably diagnostic if I
only knew enough about how iptables DNAT and proxy arp work.
Thanks: any other thoughts or any of this help in any way?
Chris
--
Daniel L. Miller
2005-01-14 22:46:31 UTC
Permalink
Post by Chris Evans
DLM> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
execute:
route del 217.34.100.194

that should kill the bogus eth2 entry.

Then see what happens.

Daniel
Chris Evans
2005-01-15 15:19:00 UTC
Permalink
Post by Chris Evans
DLM> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
DLM> execute:
DLM> route del 217.34.100.194

DLM> that should kill the bogus eth2 entry.

DLM> Then see what happens.
Nothing bogus about that entry at all and I really don't want to
delete it but can confirm that the system has the same problems when I
do. That has to be there to route things to and from the
http/https/smtp server in the dmz beyond eth2. That is served
separately from the internal network which has no need to be visible
from the outside at all. This is a pretty standard three card
hardware firewall I believe and has worked fine for some years until
recently.

I have made _some_ progress though not solved everything. First thing
I've discovered is that my ISP's DNS servers are replying through
other machines with private range IP addresses which were being
filtered out by my firewall since it is set up to ignore private
addresses from outside (on the not entirely unreasonable belief that I
think many firewalls operate that nothing should be coming to them
from those addresses). I had been assuming, stupidly, that those
iptables rejections were irrelevant. Trouble I've got now is how to
use shorewall to set the iptables commands to accept these packets
since they are coming from a private address, not the one to which the
firewall sent the request, and they're routed back to the MAC address,
not to the IP address of that interface.

I don't think that's the whole story either though and I think another
issue may be that the ISP's servers are simply sometimes very slow or
else return time outs when they shouldn't. Ugh. This is a nightmare.

Still very keen to hear any thoughts from anyone.

TIA,

Chris
Chris Evans
2005-01-15 18:00:49 UTC
Permalink
Huge thanks to those who have helped on this who may find this
interesting, and to those who have put up with the bandwidth. I put
all this to the list because increasingly I find that linux/debian
documentation is either so out of date, so incomplete, or so much
written by experts for experts, that I come to debug things from
searches of list archives.

My problem was that DNS lookups from and through my debian firewall
out through my ADSL router to my ISP's DNS servers were slow,
sometimes cripplingly slow. Lookups from my proxy arp server in a dmz
but which goes through the same firewall seemed to be fine.

Explanation (in my terms, I would hugely appreciate others who
understand arp and the ways UDP communications happen improving on or
correcting this): My ISP's DNS servers are handing back replies from
servers with private IP addresses (10.10.11.11 and 10.10.11.31 come up
in my iptables reject logs.) They send them back to the mac address of the
ethernet that put in the request. That works fine for the server in
the dmz as proxy arp on the firewall is passing messages to and from
that on the basis of its mac address. However, this system means that
replies from the servers to the firewall itself or to machines
masqueraded through it by DNAT are failing as a I don't have a rule
set up to pass things back on the basis of mac addresses. (I think the
way that shorewall 1.2, the debian stable packaged version of
shorewall, handles DNAT essentially depends on replies to queries
coming back from the IP address to which they were sent. If there's a
way to set up rules to collect up replies sent from port 53 but from
private IP addresses and enable the firewall machine to know whether
it sent the request being answered itself or forwarded it from one of
the machines inside the firewall, then I'd love to hear of it. I
don't think I dare ask on the shorewall list as 1.2 is three stable
releases out of date and about to be four behind!)

I have solved the problem in a very crude way by pointing machines
inside the firewall to the firewall itself for DNS queries. I run
bind9 on the firewall but point it (I hate this but it works) to the
dmz server. The crucial lines in /etc/bind/named.conf are:

acl "loc" {192.168.1.0/24; 217.34.100.194; 127.0.0.1; 217.34.100.197;};
# which sets up the machines allowed to query this bind service
query-source address * port 53;
# which makes it use port 53 which makes firewall rules easier
forwarders { 217.34.100.194;};
# means that it queries the dmz server for everything
allow-query { "loc"; };
# makes use of that ACL above.

I then run bind9 on the server and only allow the firewall to query
that and I tell that to lookup the ISP's servers.

/etc/resolv.conf on both machines now has only
nameserver 127.0.0.1
to get the machines only to use their own bind9 servers.

I think all this means that I get the advantage of cacheing of the DNS
requests which should cut total querying of the ISP servers
considerably I'd hope, and it works. However, it strikes me as a
horrid bodge and I'd much prefer to run bind only on the firewall and
have the dmz server lookup in the firewall, not v.v. So if someone can
see a better way, or how I could achieve that, I'd love to know.

Ugh. I do love OSS, but we do need better documentation. Bind looks
to me to be a brilliant piece of s'ware but the documentation assumes
a hell of a lot of the reader.

Cheers all,

Chris
Daniel L. Miller
2005-01-15 23:26:22 UTC
Permalink
I don't think I quite understand your setup - please help me out here.

You have a ADSL connection to the Internet. That connection is known to
your firewall as eth0.
You have a connection to your LAN - that connection is known to your
firewall as eth1.
And you have a connection to your server - that connection is known to
your firewall as eth2.

Is this correct?

If so . . .

In my unauthoritative opinion, this is how I would setup this network/DNS:

Underlying assumption - there is no physical connection between the
192.168.1/24 and 192.168.2/24 subnets - other than at the firewall
machine. Second assumption - all Internet traffic passes through the
firewall machine.

A note: I use djbdns, not bind9. Not because I'm a fanatic for or
against either one - but I've had much better luck getting djbdns to
work in a predictable and understandable manner than bind. YMMV.

1. I'm assuming somewhere on your eth1/192.168.1.0 subnet you have a
server machine. There should be a DNS server that is authoritative for
this subnet.
2. I'm inferring from your references to "server" that the
eth2/192.168.2.0 subnet has only one machine on it. You may or may not
want an authoritative DNS server for this subnet. I would just for
consistency - and will then be ready should you add backup machines.
3. On the firewall machine, there should be one or more caching DNS
servers - depending on whether or not your two subnets are allowed to
see each other. If they are, then just a single caching server that
looks to each of your subnet's authoritative servers along with your
ISP's servers. Then each of your internal machines - including the
firewall machine - should look to this one DNS server. If not - it gets
a little more complicated.

Now, routing on the firewall.

DLM> route -n
Post by Chris Evans
Post by Chris Evans
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
DLM> execute:
DLM> route del 217.34.100.194

DLM> that should kill the bogus eth2 entry.
Post by Chris Evans
Nothing bogus about that entry at all and I really don't want to
delete it but can confirm that the system has the same problems when I
do. That has to be there to route things to and from the
http/https/smtp server in the dmz beyond eth2. That is served
separately from the internal network which has no need to be visible
from the outside at all. This is a pretty standard three card
hardware firewall I believe and has worked fine for some years until
recently.
That doesn't make sense to me. Both your routing table and your
/etc/networks/interfaces show that eth2 is the 192.168.2.0 subnet.
There is nothing on that subnet that shows a 217.34.100 address. If you
have a machine on that subnet that needs to be reachable via that IP
address - that should be translated via the firewall machine. If,
however, you actually have access to the 217.34.100 subnet via eth2 -
then there should be a gateway entry in your routing table. Even if
there's only one machine in that subnet - I believe you should still
have a gateway entry. Otherwise you are showing two subnets on the
same interface - and I don't think that's right.
Post by Chris Evans
Huge thanks to those who have helped on this who may find this
interesting, and to those who have put up with the bandwidth. I put
all this to the list because increasingly I find that linux/debian
documentation is either so out of date, so incomplete, or so much
written by experts for experts, that I come to debug things from
searches of list archives.
You are helping to write the documentation by generating these posts.
Post by Chris Evans
My problem was that DNS lookups from and through my debian firewall
out through my ADSL router to my ISP's DNS servers were slow,
sometimes cripplingly slow. Lookups from my proxy arp server in a dmz
but which goes through the same firewall seemed to be fine.
I just saw something. Please define "Proxy ARP Server". Is this
another Debian machine or something else? What DNS servers (ip
addresses) is this machine using?

--
Daniel
Chris Evans
2005-01-16 11:58:50 UTC
Permalink
If there are wizards who know iptables, proxy arp, SNAT, DNAT and
perhaps shorewall who could spare time to read this, it may help
Daniel and I build the emerging FAQ here on what I think is probably
going to hit other people in the future....

Saturday, January 15, 2005, 11:26:22 PM, Daniel wrote:

DLM> I don't think I quite understand your setup - please help me out here.

DLM> You have a ADSL connection to the Internet. That connection is known to
DLM> your firewall as eth0.
DLM> You have a connection to your LAN - that connection is known to your
DLM> firewall as eth1.
DLM> And you have a connection to your server - that connection is known to
DLM> your firewall as eth2.

DLM> Is this correct?

Yes.

DLM> If so . . .

DLM> In my unauthoritative opinion, this is how I would setup this network/DNS:

DLM> Underlying assumption - there is no physical connection between the
DLM> 192.168.1/24 and 192.168.2/24 subnets - other than at the firewall
DLM> machine. Second assumption - all Internet traffic passes through the
DLM> firewall machine.
Correct

DLM> A note: I use djbdns, not bind9. Not because I'm a fanatic for or
DLM> against either one - but I've had much better luck getting djbdns to
DLM> work in a predictable and understandable manner than bind. YMMV.
Understood. I tried djbdns and, though I'm not taken with bind
documentation, for some reason couldn't get djbdns working, hence bind
now.

DLM> 1. I'm assuming somewhere on your eth1/192.168.1.0 subnet you have a
DLM> server machine. There should be a DNS server that is authoritative for
DLM> this subnet.
No, only two machines in that network, both Windoze, no server and
static IP addresses set for the machines suffice.

DLM> 2. I'm inferring from your references to "server" that the
DLM> eth2/192.168.2.0 subnet has only one machine on it. You may or may not
DLM> want an authoritative DNS server for this subnet. I would just for
DLM> consistency - and will then be ready should you add backup machines.
Correct, again, my understanding was that its own /etc/hosts content
suffices here as it's the only machine here.

DLM> 3. On the firewall machine, there should be one or more caching DNS
DLM> servers - depending on whether or not your two subnets are allowed to
DLM> see each other. If they are, then just a single caching server that
DLM> looks to each of your subnet's authoritative servers along with your
DLM> ISP's servers. Then each of your internal machines - including the
DLM> firewall machine - should look to this one DNS server. If not - it gets
DLM> a little more complicated.
I would have liked to have done that, but the way that the ISP is
returning replies from its DNS servers makes this impossible. They
come back from various different private IP addresses (10.10.11.11 and
10.10.11.31 so far) and are routed to the mac address of the firewall
machine. BT assume I am not running NAT hence I guess they're in
their rights to do this but I am running NAT here and that means the
poor old firewall iptables, as far as I can see, can't know what to do
with these replies. I may be wrong about that, probably am, but can't
see how to instruct it that all replies from port 53 addresses should
be assumed to be replies to its own requests even if the requests went
out to different IP address than is sending back the response.

DLM> Now, routing on the firewall.

DLM>> route -n
Post by Chris Evans
Post by Chris Evans
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
DLM>> execute:
DLM>> route del 217.34.100.194

DLM>> that should kill the bogus eth2 entry.
Post by Chris Evans
Nothing bogus about that entry at all and I really don't want to
delete it but can confirm that the system has the same problems when I
do. That has to be there to route things to and from the
http/https/smtp server in the dmz beyond eth2. That is served
separately from the internal network which has no need to be visible
from the outside at all. This is a pretty standard three card
hardware firewall I believe and has worked fine for some years until
recently.
DLM> That doesn't make sense to me. Both your routing table and your
DLM> /etc/networks/interfaces show that eth2 is the 192.168.2.0 subnet.
DLM> There is nothing on that subnet that shows a 217.34.100 address. If you
DLM> have a machine on that subnet that needs to be reachable via that IP
DLM> address - that should be translated via the firewall machine. If,
DLM> however, you actually have access to the 217.34.100 subnet via eth2 -
DLM> then there should be a gateway entry in your routing table. Even if
DLM> there's only one machine in that subnet - I believe you should still
DLM> have a gateway entry. Otherwise you are showing two subnets on the
DLM> same interface - and I don't think that's right.
I may be wrong, I have a sense that there are people watching our
exchange with quiet amusement (well, would if they read this far) who
really know this stuff ... but ...

That server has to be addressable as 217.34.100.194 as I have the
psyctc.org. 15186 IN NS ns0.intercityuk.com.
psyctc.org. 15186 IN NS ns0.blackcatnetworks.co.uk.
psyctc.org. 15186 IN NS ns1.blackcatnetworks.co.uk.
ns0.intercityuk.com. 83318 IN A 195.82.119.192
ns0.blackcatnetworks.co.uk. 21190 IN A 193.201.200.34
ns1.blackcatnetworks.co.uk. 21188 IN A 69.55.225.40
That has to be accessible from the outside world for http, https and
smtp.

My understanding is that there are two ways of doing this on the
firewall: proxy arp, which I have used which uses mac addresses, and
SNAT. I simply went for proxy arp years ago when I first installed
the firewall machine and shorewall and it's always run fine. That
machine can get to the outside and v.v. I find it hard to believe
that the routing table is wrong.

DLM> I just saw something. Please define "Proxy ARP Server". Is this
DLM> another Debian machine or something else? What DNS servers (ip
DLM> addresses) is this machine using?
Perhaps that was a bad term, I meant that server and that it is
"served" to the outside world for those three ports (http, https and
smtp only I think) by "proxy arp" which I believe means that any
package it sends to the firewall (and there's nowhere else it can send
anything) is passed on with the firewall putting the IP address and
the mac address of that machine, not its own eth0 mac address, on all
the packages it transfers. When a package comes back for that mac
address, the firewall knows to send it to that server. I think that's
different from NAT where the packages go out with the IP address and
mac address of the eth0 firewall interface and the kernel, through
iptables magic, works out where to send reply packages on the basis of
their IP address and what machine inside the firewall was talking to
that port and that IP address. That system is being messed up for the
firewall by my ISP's way of sending DNS replies.

Let me know if this makes any more sense. For now, I have a slightly
slow DNS system that just about works and another "just about": I'm
just about out of time for this and have to return to my main job for
a week or so with fingers crossed!!

Yuck!

C
Daniel L. Miller
2005-01-17 01:26:48 UTC
Permalink
Post by Chris Evans
If there are wizards who know iptables, proxy arp, SNAT, DNAT and
perhaps shorewall who could spare time to read this, it may help
Daniel and I build the emerging FAQ here on what I think is probably
going to hit other people in the future....
DLM> I don't think I quite understand your setup - please help me out here.
DLM> You have a ADSL connection to the Internet. That connection is known to
DLM> your firewall as eth0.
DLM> You have a connection to your LAN - that connection is known to your
DLM> firewall as eth1.
DLM> And you have a connection to your server - that connection is known to
DLM> your firewall as eth2.
DLM> Is this correct?
Yes.
DLM> If so . . .
DLM> Underlying assumption - there is no physical connection between the
DLM> 192.168.1/24 and 192.168.2/24 subnets - other than at the firewall
DLM> machine. Second assumption - all Internet traffic passes through the
DLM> firewall machine.
Correct
DLM> A note: I use djbdns, not bind9. Not because I'm a fanatic for or
DLM> against either one - but I've had much better luck getting djbdns to
DLM> work in a predictable and understandable manner than bind. YMMV.
Understood. I tried djbdns and, though I'm not taken with bind
documentation, for some reason couldn't get djbdns working, hence bind
now.
I had a miserable time working my way through bind, djbdns, dnsmasq,
maradns, and powerdns - until I finally found some reference materials
and some support from the djbdns group. I may actually understand it
now! If you wanna try again let me know.
Post by Chris Evans
DLM> 1. I'm assuming somewhere on your eth1/192.168.1.0 subnet you have a
DLM> server machine. There should be a DNS server that is authoritative for
DLM> this subnet.
No, only two machines in that network, both Windoze, no server and
static IP addresses set for the machines suffice.
DLM> 2. I'm inferring from your references to "server" that the
DLM> eth2/192.168.2.0 subnet has only one machine on it. You may or may not
DLM> want an authoritative DNS server for this subnet. I would just for
DLM> consistency - and will then be ready should you add backup machines.
Correct, again, my understanding was that its own /etc/hosts content
suffices here as it's the only machine here.
DLM> 3. On the firewall machine, there should be one or more caching DNS
DLM> servers - depending on whether or not your two subnets are allowed to
DLM> see each other. If they are, then just a single caching server that
DLM> looks to each of your subnet's authoritative servers along with your
DLM> ISP's servers. Then each of your internal machines - including the
DLM> firewall machine - should look to this one DNS server. If not - it gets
DLM> a little more complicated.
OK. Bind9 acts as both a caching server and an authoritative server. I
would setup DNS zones on your firewall server for each of your two
subnets, and have each of your interior computers (both subnets) look to
the firewall server. So you wind up with a single physical DNS server,
and via Bind9, a single (sort of) DNS process for all your computers to
resolve from.
Post by Chris Evans
I would have liked to have done that, but the way that the ISP is
returning replies from its DNS servers makes this impossible. They
come back from various different private IP addresses (10.10.11.11 and
10.10.11.31 so far) and are routed to the mac address of the firewall
machine. BT assume I am not running NAT hence I guess they're in
their rights to do this but I am running NAT here and that means the
poor old firewall iptables, as far as I can see, can't know what to do
with these replies. I may be wrong about that, probably am, but can't
see how to instruct it that all replies from port 53 addresses should
be assumed to be replies to its own requests even if the requests went
out to different IP address than is sending back the response.
Here again - I have trouble, because I don't use shorewall! Not that
I'm trying to change the tools you've been using - but I've been using
firehol with great success. But since shorewall is also iptables based
- this shouldn't be TOO much of a problem. We may have to look a bit
more at your firewall config. I don't understand what you need NAT for
- in regards to DNS.

You have a firewall/DNS server directly connected to your ADSL on eth0.
That interface has an Internet IP. There should be nothing to NAT
here. Maybe you're doing something different - the basic premise my own
firewall operates on is:
1. Allow OUT anything from my internal network - outbound requests
are SNATed.
1a. Allow IN anything specifically requested.
2. Allow IN via DNAT specific services - such as http, imap, etc.
3. Flatly block anything else.

Unless you need to allow inbound queries for DNS (and you haven't
indicated that) - NAT should have nothing to do with your DNS.
Post by Chris Evans
DLM> Now, routing on the firewall.
DLM>> route -n
Post by Chris Evans
Post by Chris Evans
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
DLM>> route del 217.34.100.194
DLM>> that should kill the bogus eth2 entry.
Post by Chris Evans
Nothing bogus about that entry at all and I really don't want to
delete it but can confirm that the system has the same problems when I
do. That has to be there to route things to and from the
http/https/smtp server in the dmz beyond eth2. That is served
separately from the internal network which has no need to be visible
from the outside at all. This is a pretty standard three card
hardware firewall I believe and has worked fine for some years until
recently.
I'm gonna come back to this.
Post by Chris Evans
DLM> That doesn't make sense to me. Both your routing table and your
DLM> /etc/networks/interfaces show that eth2 is the 192.168.2.0 subnet.
DLM> There is nothing on that subnet that shows a 217.34.100 address. If you
DLM> have a machine on that subnet that needs to be reachable via that IP
DLM> address - that should be translated via the firewall machine. If,
DLM> however, you actually have access to the 217.34.100 subnet via eth2 -
DLM> then there should be a gateway entry in your routing table. Even if
DLM> there's only one machine in that subnet - I believe you should still
DLM> have a gateway entry. Otherwise you are showing two subnets on the
DLM> same interface - and I don't think that's right.
I may be wrong, I have a sense that there are people watching our
exchange with quiet amusement (well, would if they read this far) who
really know this stuff ... but ...
That server has to be addressable as 217.34.100.194 as I have the
psyctc.org. 15186 IN NS ns0.intercityuk.com.
psyctc.org. 15186 IN NS ns0.blackcatnetworks.co.uk.
psyctc.org. 15186 IN NS ns1.blackcatnetworks.co.uk.
ns0.intercityuk.com. 83318 IN A 195.82.119.192
ns0.blackcatnetworks.co.uk. 21190 IN A 193.201.200.34
ns1.blackcatnetworks.co.uk. 21188 IN A 69.55.225.40
That has to be accessible from the outside world for http, https and
smtp.
My understanding is that there are two ways of doing this on the
firewall: proxy arp, which I have used which uses mac addresses, and
SNAT. I simply went for proxy arp years ago when I first installed
the firewall machine and shorewall and it's always run fine. That
machine can get to the outside and v.v. I find it hard to believe
that the routing table is wrong.
I don't know anything about proxy arp - maybe someone out there laughing
at us want's to chime in here? I use DNAT - never had a problem.
Post by Chris Evans
DLM> I just saw something. Please define "Proxy ARP Server". Is this
DLM> another Debian machine or something else? What DNS servers (ip
DLM> addresses) is this machine using?
Perhaps that was a bad term, I meant that server and that it is
"served" to the outside world for those three ports (http, https and
smtp only I think) by "proxy arp" which I believe means that any
package it sends to the firewall (and there's nowhere else it can send
anything) is passed on with the firewall putting the IP address and
the mac address of that machine, not its own eth0 mac address, on all
the packages it transfers. When a package comes back for that mac
address, the firewall knows to send it to that server. I think that's
different from NAT where the packages go out with the IP address and
mac address of the eth0 firewall interface and the kernel, through
iptables magic, works out where to send reply packages on the basis of
their IP address and what machine inside the firewall was talking to
that port and that IP address. That system is being messed up for the
firewall by my ISP's way of sending DNS replies.
I still don't understand how your firewall is blocking DNS REPLIES -
unless something is really messed up!


I'm also concerned about something else you stated in your original post
- that just clicked. You said this config has been working fine - and
just started to have problems. What changed?

Daniel
Chris Evans
2005-01-17 06:28:08 UTC
Permalink
Monday, January 17, 2005, 1:26:48 AM, Daniel wrote:

...lots snipped which I'll come back to some time when I'm not dashing
to main work! ...

DLM> I'm also concerned about something else you stated in your original post
DLM> - that just clicked. You said this config has been working fine - and
DLM> just started to have problems. What changed?
I'm pretty sure that what has changed is the way that my ISP is
replying to DNS requests: they used to come back from the IP address
of the server you queried (I suspect), now most replies are offloaded
to a machine on a private address (and not the one you queried).
That's causing the problem as my firewall set up can't see that those
are replies to its requests whereas the proxy arp server going through
it can since the firewall identifies and passes to it its replies on
the basis of its mac address.

Cheers,

C

Chris Evans
2005-01-15 15:11:02 UTC
Permalink
Post by Chris Evans
DLM> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
DLM> Based on your other post - do you have three physical network
DLM> connections on this computer? Three seperate network cards?

Yes! One to ADSL router (eth0), one to switch for firewalled off
internal network (eth1) and one to proxy arp served up server in the
DMZ (eth2).

Cheers,

Chris
Chris Evans
2005-01-14 08:25:49 UTC
Permalink
Thursday, January 13, 2005, 9:24:36 PM, Daniel wrote:

DLM> Did you get this resolved?
No. Sorry if it seemed like I went offline: I did really: main job
work.

Chris
Continue reading on narkive:
Loading...