Guest User!

You are not Sophos Staff.

[9.080][BUG] after update DNS doesn't run

Hallo

after upgrade to 9.080 the interfaces are up, in error state and DNS don't run. 

But only the Astaro can not use the DNS anymore, my DNS Server beding the UTM is able to resolve every name.

here is the system.log:

2013:03:29-19:13:52 firewall-1 dns-resolver[4358]: Updating REF_ftMupyRPBY :: nds2.fds-fire.nokia.com

2013:03:29-19:13:58 firewall-1 init: Switching to runlevel: 6
2013:03:29-19:14:11 firewall-1 ulogd[4592]: SIGTERM received
2013:03:29-19:14:13 firewall-1 postgres[3766]: [3-1] LOG:  received fast shutdown request
2013:03:29-19:14:13 firewall-1 postgres[3766]: [4-1] LOG:  aborting any active transactions
2013:03:29-19:14:13 firewall-1 postgres[13808]: [3-1] FATAL:  terminating connection due to administrator command
2013:03:29-19:14:13 firewall-1 postgres[13809]: [3-1] FATAL:  terminating connection due to administrator command
2013:03:29-19:14:13 firewall-1 postgres[3771]: [3-1] LOG:  autovacuum launcher shutting down
2013:03:29-19:14:14 firewall-1 postgres[3768]: [2-1] LOG:  shutting down
2013:03:29-19:14:14 firewall-1 postgres[3768]: [3-1] LOG:  database system is shut down
2013:03:29-19:14:17 firewall-1 syslog-ng[2798]: Termination requested via signal, terminating;
2013:03:29-19:14:17 firewall-1 syslog-ng[2798]: syslog-ng shutting down; version='3.0.10'
2013:03:29-19:15:44 firewall-1 syslog-ng[2796]: Configuration reload request received, reloading configuration;
2013:03:29-19:15:44 firewall-1 ulogd[3769]: SIGTERM received
2013:03:29-19:15:46 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:15:48 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:15:57 firewall-1 ddclient[5394]: WARNING:  cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.org'
2013:03:29-19:16:05 firewall-1 snmpd[4286]: Received TERM or STOP signal...  shutting down...
2013:03:29-19:16:06 firewall-1 snmpd[6026]: NET-SNMP version 5.6.2
2013:03:29-19:16:10 firewall-1 system: System was restarted
2013:03:29-19:16:49 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:17:01 firewall-1 /usr/sbin/cron[7288]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2013:03:29-19:17:49 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:18:49 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:19:49 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:19:59 firewall-1 ntpd[4312]: Deleting interface #5 eth1, 192.168.100.100#123, interface stats: received=0, sent=0, dropped=0, active_time=263 secs
2013:03:29-19:19:59 firewall-1 ntpd[4312]: Deleting interface #4 eth1, 62.40.184.154#123, interface stats: received=0, sent=0, dropped=0, active_time=263 secs
2013:03:29-19:19:59 firewall-1 ntpd[4312]: peers refreshed
2013:03:29-19:20:01 firewall-1 /usr/sbin/cron[7631]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2013:03:29-19:20:10 firewall-1 ntpd[4312]: Listen normally on 13 eth1 62.40.184.154 UDP 123
2013:03:29-19:20:10 firewall-1 ntpd[4312]: Listen normally on 14 eth1 192.168.100.100 UDP 123
2013:03:29-19:20:10 firewall-1 ntpd[4312]: 86.59.80.170 interface 193.238.156.17 -> 62.40.184.154
2013:03:29-19:20:10 firewall-1 ntpd[4312]: 91.206.8.70 interface 193.238.156.17 -> 62.40.184.154
2013:03:29-19:20:10 firewall-1 ntpd[4312]: 194.11.27.31 interface 193.238.156.17 -> 62.40.184.154
2013:03:29-19:20:10 firewall-1 ntpd[4312]: peers refreshed
2013:03:29-19:20:10 firewall-1 ntpd[4312]: new interface(s) found: waking up resolver
2013:03:29-19:20:50 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:20:57 firewall-1 ddclient[5394]: WARNING:  cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.org'
2013:03:29-19:21:50 firewall-1 dns-resolver[4322]: DNS server failed to contact!
2013:03:29-19:22:50 firewall-1 dns-resolver[4322]: DNS server failed to contact!


firewalllog:

20:03:53	Default DROP	UDP	

62.40.***.*** : 13020

8.8.8.8 : 53
len=71 ttl=64 tos=0x00 srcmac=0:1a:8c:16[:D]b:a9


The 62.40.***.*** is the external IP from the UTM.

i make a any - DNS - any rule, but the UTM blocks the traffic from the UTM. The internal Network can use public DNS, only the UTM has a problem.
  • Hi, what kind of NICs and/or VM drivers are you using?

    Barry
  • i go back one version and restore the same configuration and this works, only if i upgrade to 9.080 every DNS request vom UTM will blocked.
  • Do you have DNSSEC validation enabled under Network Services ->DNS . I believe that is what causes this problem and it is not new to 9.80 I have had these entries from previous betas also. For example one of my forwarders 64.81.127.2 is not DNSSEC capable so I get these errors in the DNS logs
    2013:03:30-21:34:34 gatekeeper named[4337]: error (no valid RRSIG) resolving '168.192.in-addr.arpa/DS/IN': 64.81.127.2#53
    2013:03:30-21:35:33 gatekeeper named[4337]:   validating @0x90bcfa0: net SOA: got insecure response; parent indicates it should be secure
    2013:03:30-21:35:33 gatekeeper named[4337]: error (no valid RRSIG) resolving 'globalsign.net/DS/IN': 64.81.127.2#53
    2013:03:30-21:35:38 gatekeeper named[4337]:   validating @0x90bcfa0: com SOA: got insecure response; parent indicates it should be secure
    2013:03:30-21:35:38 gatekeeper named[4337]: error (no valid RRSIG) resolving 'geotrust.com/DS/IN': 64.81.127.2#53
    2013:03:30-21:35:39 gatekeeper named[4337]:   validating @0x90bcfa0: net SOA: got insecure response; parent indicates it should be secure
    2013:03:30-21:35:39 gatekeeper named[4337]: error (no valid RRSIG) resolving 'geotrust.net/DS/IN': 64.81.127.2#53

    But I haven't found the correlation between the time the error is displayed in DNS log to the entries in the system log.
    In system log
    2013:03:30-21:40:01 gatekeeper /usr/sbin/cron[8834]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
    2013:03:30-21:40:05 gatekeeper dns-resolver[4322]: DNS server failed to contact!
    2013:03:30-21:41:16 gatekeeper dns-resolver[4322]: DNS server failed to contact!
    2013:03:30-21:42:26 gatekeeper dns-resolver[4322]: DNS server failed to contact!
    2013:03:30-21:43:36 gatekeeper dns-resolver[4322]: DNS server failed to contact!
    2013:03:30-21:44:46 gatekeeper dns-resolver[4322]: DNS server failed to contact!


    Regards
    Bill
  • Do you have DNSSEC validation enabled under Network Services ->DNS .


    Hi Billybob,

    i don't enabled DNSSEC, for now i go back to the version before. You find here a lot of errors with blocking content. I think DNS is only one part that don't work in 9.080 Version.
  • with the last update the firewall blocks all DNS update too. Take a look to the screenshot. 

    A dns rule don't change anything!

    i turn off: application control, web filtering and all things that i don't need, but nothing changed. 

    The interface state will be shown wrong too, a interface can not be in error or down if it makes traffic.

    the only way is to go back to 9.070.
  • Hi Alex,

    We are checking your problem.
    Do you have Uplink Balancing/ UL Monitoring enabled? Multiple Default gateways on several interfaces can cause the interface to get in Link state: error. Could you provide service-monitor.log if this option is enabled?

    Do you want to use the UTM as a DNS Resolver?In this case you need an AUTO_INPUT chain in iptables. For this you need to add your Internal Network in the DNS->Global->Allowed Networks. 
    Or do you want to use an external DNS Resolver? Did you configure a DNS Forwarder?
    Please provide output of the command: iptables-save | grep 53

    Thanks,
    Bianca
  • Hi Tinkerbell,

    i have 2 interfaces with one that have Link Balancing - the wired one with 100, the air one with 0. So i have a kind of failover configuration.

    The Linkmonitor is running, but if i disable it on 7.080 and later, the DNS and all traffic direct from the firewall was blocking. This don't change anything.

    You can have ssh and webmin access to the firewall and we can search the probem.
  • Thanks for reporting. We are now tracking this as Mantis ID #25211