Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - MikeHartman

Pages: [1] 2
1
That yggdrasil machine is the one running Zentyal. I don't know why it would show the name rather than the IP or fqdn but I don't know iptables at all.

This is just a personal network, so the domain was just something I picked during Zentyal setup. It's true that the zentyal machine and the domain share a name. It didn't occur to me that it would be a problem, and it doesn't seem like it has been up until now (it's been running for at least a year or two), but it's something I can take a look at.

I thought about upgrading Zentyal when I started researching this problem and saw how old my version is. But this Zentyal install is how my household connects to the internet (and I telecommute). So taking it offline for hours while I do an upgrade isn't easy. And that's assuming the upgrade goes smoothly. If I encounter problems I could be offline for days.

If I could do a simple in-place upgrade I'd probably risk it.  But all the directions I've found are more along the lines of taking a backup, installing a brand-new Zentyal from scratch, and then trying to restore from the backup. Not wild about that. Maybe if all else fails, but I'm not there yet.

2
Zentyal Version: 2.0.23

My Firewall packet filter setup is extremely simple:

  • Filtering rules from internal networks to Zentyal
       
    • Decision=Drop, Source=Any, Service=ldap
    • Decision=Accept, Source=Any, Service=Any
     
  • Filtering rules for internal networks
       
    • Decision=Accept, Source=Any, Destination=Any, Service=Any
     
  • Filtering rules for traffic coming out from Zentyal
       
    • Decision=Accept, Destination=Any, Service=Any
     
  • Filtering rules from external networks to Zentyal
       
    • Decision=Drop, Source=Any, Service=VoIP
     
  • Filtering rules from external networks to internal networks
       
    • No rules
     
  • Rules added by Zentyal services (Advanced)
       
    • A couple pages of rules, all with Decision=Accept
     

Basically, anything originating in the internal network should be able to go wherever it wants.

This generally works on most of my machines. From 192.168.1.11 (odin) I can ping 192.168.1.1 (yggdrasil, where zentyal is running), 192.168.1.60 (hermod) and addresses on the internet.

But from hermod, I can only ping odin. If I try to ping yggdrasil (zentyal) it times out with no response. If I try to ping an address on the internet it times out with no response. If I try to ssh to zentyal it times out with no response. Zentyal is also responsible for my DNS and ignores those requests as well. I have yet to find any connection type that will work between hermod and zentyal or hermod and the internet.

Despite my very permissive firewall rules, it's the firewall that's blocking it. If I view the firewall logs I can see every connection attempt from hermod is dropped. Example screenshot attached.

Hermod joins the network with DHCP the same way odin does. There's no reason zentyal should be treating it differently. And I have almost nothing but "allow all" rules for the internal stuff. What could be the problem?

I'm attaching the output of iptables -L for reference, but I have no idea how to read it, or fix it if the Zentyal firewall interface isn't setting it up correctly.

Also, here's some output from /var/log/debug as I'm trying to ping zentyal and a google server from hermod:

May 31 00:51:35 yggdrasil kernel: [ 3283.078065] ebox-firewall drop IN=eth0 OUT=eth1 SRC=192.168.1.60 DST=74.125.131.105 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1384 SEQ=1 MARK=0x1
May 31 00:51:36 yggdrasil kernel: [ 3284.078218] ebox-firewall drop IN=eth0 OUT=eth1 SRC=192.168.1.60 DST=74.125.131.105 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1384 SEQ=2 MARK=0x1
May 31 00:54:46 yggdrasil kernel: [ 3473.858712] ebox-firewall drop IN=eth0 OUT= MAC=00:06:5b:fe:83:59:a0:88:b4:41:36:dc:08:00 SRC=192.168.1.60 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1386 SEQ=1 MARK=0x1
May 31 00:54:47 yggdrasil kernel: [ 3474.858519] ebox-firewall drop IN=eth0 OUT= MAC=00:06:5b:fe:83:59:a0:88:b4:41:36:dc:08:00 SRC=192.168.1.60 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1386 SEQ=2 MARK=0x1

3
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 12:51:09 pm »
Although interestingly, doing an nslookup on a completely fake domain looks a little different:

nslookup monkey.monkey
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server:      4.2.2.2
Address:   4.2.2.2#53

** server can't find monkey.monkey: NXDOMAIN

There's one less line that looks like ";; Got SERVFAIL reply from 127.0.0.1, trying next server". The hartman lookup had two of those.

I wonder if the first line is Zentyal (127.0.0.1) saying "yes, I've heard of the "hartman" domain. Try asking 127.0.0.1" and then the second line is (a different piece of?) Zentyal saying "I don't know what you're talking about". Is that possible? Are the different db files in /etc/bind representative of different hops along the resolution path? Or different sub-processes of bind?

Anyway, it's almost 7am here and I've been up all night so I'm heading to bed. Keep the suggestions coming by all means though. This is driving me crazy.

4
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 12:45:33 pm »
On the Zentyal server:

dig hartman AXFR

; <<>> DiG 9.7.0-P1 <<>> hartman AXFR
;; global options: +cmd
; Transfer failed.

Looks the same as it did from the laptop. Nslookups don't look any better from there either:

nslookup wifia
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server:      127.0.0.1
Address:   127.0.0.1#53

** server can't find wifia: NXDOMAIN

nslookup wifia.hartman
;; Got SERVFAIL reply from 127.0.0.1, trying next server
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server:      4.2.2.2
Address:   4.2.2.2#53

** server can't find wifia.hartman: NXDOMAIN

Plus the DNS was at least partially working (FQDN only) when it was set up as dynamic, so I guess the firewall was letting it through on that port at one point.

5
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 12:32:43 pm »
My named.conf.local is also in /etc/bind and looks like:

Quote
acl "trusted" {
   localhost;
   localnets;
};

zone "hartman" {
   type master;
   file "/etc/bind/db.hartman";
};

zone "1.168.192.in-addr.arpa" {
   type master;
        file "/etc/bind/db.1.168.192";           
};
zone "0.0.127.in-addr.arpa" {
   type master;
        file "/etc/bind/db.0.0.127";           
};

/etc/bind/db.1.168.192 contains:

Quote

$TTL 3D
$ORIGIN 1.168.192.in-addr.arpa.
@   IN   SOA   ns.hartman.   hostmaster.hartman. (
         2011092806   ;serial number
         8H      ;refresh
         2H      ;retry
         4W      ;expiration
         1D )      ;
;
      NS   ns.hartman.   ;nameserver
;
2   PTR   wifia.hartman.
1   PTR   hartman.


and /etc/bind/db.0.0.127 contains:

Quote
$TTL 3D
$ORIGIN 0.0.127.in-addr.arpa.
@   IN   SOA   ns.hartman.   hostmaster.hartman. (
         2011092806   ;serial number
         8H      ;refresh
         2H      ;retry
         4W      ;expiration
         1D )      ;
;
      NS   ns.hartman.   ;nameserver
;
1   PTR   ns.hartman.

I also tried watching the logs on the Zentyal system, but doing an nslookup on "wifia" or "wifia.hartman" from the laptop didn't trigger any activity in /var/log or /var/log/ebox. I don't see a separate log anywhere for bind.

6
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 12:16:09 pm »
Yep, I've tried restarting the DNS module and the Zentyal box itself several times. No dice.

I have no /etc/named.conf.local. However, I think I found my db files in /etc/bind.

cat /etc/bind/db.hartman
$TTL 3D
@   IN   SOA   .hartman.   hostmaster (
         2011092806   ;serial number
         8H      ;refresh
         2H      ;retry
         4W      ;expiration
         1D )      ;
;
@      A   192.168.1.1
@               NS     
@               NS      ns
wifia      A   192.168.1.30
wifib      A   192.168.1.31
ns      A   127.0.0.1



7
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 12:02:48 pm »
There's nothing in /var/lib/bind. But the DNS module says it's running in the web interface. Is there something else I need to do to force it to run?

8
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 11:39:40 am »
It hasn't changed much since my first post:

DNS->List of Domains
  "hartman"
    hostnames
      "ns" - 127.0.0.1  // whether this is here or not seems to make no difference
      "wifia" - 192.168.1.30
      "wifib" - 192.168.1.31
  Dynamic? - no

9
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 11:22:13 am »
The DNS module says it's running...

And it was working (at least the FQDN) when it was running as dynamic instead of static.

10
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 10:53:30 am »
Strange isn't it?
and what's about "dig wifia.hartman" ? or faster for investigation "dig hartman AXFR"...
I suspect DNS issue...

"dig wifia.hartman" gives the same SERVFAIL message.

"dig hartman AXFR" gives a different error:

; <<>> DiG 9.7.3 <<>> hartman AXFR
;; global options: +cmd
; Transfer failed.

11
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 10:51:59 am »
I was googling around and found this:

Quote
SERVFAIL means that the domain does exist and the root name servers have information on this domain, but that the authoritative name servers are not answering queries for this domain.

Given that in my case Zentyal is both the root name server and the authoritative name server for that domain, this seems weird. The Zentyal DNS knows the domain exists but isn't answering queries for it?

Are there logs somewhere on the Zentyal box I can check to see what problem it's encountering that causes the SERVFAIL packet?

12
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 10:38:24 am »
dig hartman ANY

; <<>> DiG 9.7.3 <<>> hartman ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34366
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hartman.         IN   ANY

;; Query time: 11 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Sep 28 04:36:59 2011
;; MSG SIZE  rcvd: 27

13
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 10:36:32 am »
I can't see in your explanation where and when you added wifia host in DNS for "hartman" domain.

Third and fourth lines:

Quote from: MikeHartman
The "hartman" domain is now marked "Dynamic? - No" and has only two host entries under it.

wifia 192.168.1.30
wifib 192.168.1.31

The source of IP is definitely NOT an issue. what matters is to ensure you are using, on machine used to search, the right search domain that is either configured manually or inherited from DHCP. This is what matter.

Quote from: MikeHartman
cat /etc/resolv.conf
# Generated by NetworkManager
domain hartman
search hartman
nameserver 192.168.1.1

Behaviour with "nslookup wifia", assuming such entry already exists as host in DNS, lokks like you typed "nslookup wifia." (notice the extra tailing dot)

I didn't though. What I included in the previous post is the exact contents of my screen - both the command I entered and the output it gave me.

You should NOT edit network settings if your machine is configured to use DHCP otherwise it might be a bit inconsistent and confusing for further investigation.

Agreed. I was just tweaking it to see how much of my problem might be in the config Zentyal is sending to the laptop and how much of it might be in the behind-the-scenes process where Zentyal is handling the lookup request. If it turned out that manually doing something to the laptop's /etc/resolv.conf fixed the problem then it would just be a matter of figuring out what to tweak in Zentyal to get the /etc/resolv.conf to generate that way automatically.

At any rate, no such tweaks are meant to persist. Every time I make a change in Zentyal or want to test something new I freshen my /etc/resolv.conf by leaving and rejoining the network. It gets reset every time.

14
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 10:03:51 am »
Ok. I've removed "wifia" and "wifib" from the list of fixed addresses. DHCP now knows nothing about them. They are still statically configured to 192.168.1.30 and 192.168.1.31 on the clients themselves.

I've turned off the dynamic DNS from the DHCP page, but left "hartman" as the search domain.

The "hartman" domain is now marked "Dynamic? - No" and has only two host entries under it.

wifia 192.168.1.30
wifib 192.168.1.31

This is about as simple a static DNS setup as I can think of. I've saved all the changes in Zentyal's web interface.

The machine I'm trying to reach them from is a laptop connected via DHCP (and DHCP is giving it a fixed IP but I don't think the source of the laptop's IP should be an issue here). It's running Ubuntu (and thus Network Manager) for what it's worth.

nslookup wifia
Server:      192.168.1.1
Address:   192.168.1.1#53

** server can't find wifia: NXDOMAIN

nslookup wifia.hartman
Server:      192.168.1.1
Address:   192.168.1.1#53

** server can't find wifia.hartman.hartman: SERVFAIL

cat /etc/resolv.conf
# Generated by NetworkManager
domain hartman
search hartman
nameserver 192.168.1.1

So when I only enter the hostname, neither the client nor Zentyal bother adding the domain. But when I use the FQDN it looks like at least one of them is, even though it doesn't need it? Or is that because the FQDN I'm entering doesn't produce a result, so adding the search domain is just the automatic next attempt?

If I manually remove both the domain and search lines from /etc/resolv.conf I get different FQDN behavior but the hostnames still don't work. I assume this is because the laptop no longer knows about a domain to attempt as a fallback.

nslookup wifia.hartman
Server:      192.168.1.1
Address:   192.168.1.1#53

** server can't find wifia.hartman: SERVFAIL



15
Installation and Upgrades / Re: Zentyal-powered LAN DNS not working?
« on: September 28, 2011, 09:12:06 am »
Robb is right. Those APs ("wifia" and "wifib") are configured statically on the client-side and not really coming through DHCP, and thus probably won't work with the dynamic DNS setup. There are two separate issues:

1) When I try to use a "dynamic" DNS configuration only the FQDN works. Just using the hostname does not (host not found). This is the configuration I included, because it at least partially works. I'm aware that this wouldn't incorporate those static APs, but at this point I'm just trying to get anything I can working.

2) When I try to use a "static" DNS configuration, manually specifying a bunch of hostname/IP pairs under the domain instead, it does not work at all. Not with FQDN. Not with hostname. It's as if the DNS records aren't even there. This is even more significant to me since, as Robb clarified, those APs are configured statically even though they have a DHCP IP "reserved" so this is my only way of accessing them.

So I think the only way to get full DNS resolution across all devices is to maintain a static list (#2). Which doesn't bother me much, because all the DHCP clients I care about have been set up with fixed IPs anyway, but it doesn't work. And I'm thinking #1 might still be an issue, because if the search domain is not being used correctly that could easily be independent of how the actual DNS entries are managed.

I really think I need both issues resolved before I'll have working DNS to all members of my network.

I don't think nslookup will be any better than ping for this since I can ping the clients' IP addresses directly, just not via the hostnames. That seems to rule out a network issue and isolate it to resolution. But I'll try a few nslookups just to see if it makes a difference.

Pages: [1] 2