Bind / IPTABLES issue

Discussion in 'Installation/Configuration' started by ybz, Oct 30, 2009.

  1. ybz

    ybz New Member

    Hello,

    The problem is as follows:
    Queries to Bind9 outside localhost fail on clean installation of ISPConfig 2.2.23 on Ubuntu Server 9.04. I have a very similar configuration in another similar network and everything works perfect there.

    I believe it has to do with communicating with the router (probably an IPTABLES issue), but did not manage to pinpoint the problem.

    I have also tried to channel all traffic to go only via port 53 (see named.conf below), but it does not help. I keep getting highports traffic outside the localhost (blocked by firewall on the clients) as response to DNS queries outside the localhost. TCPDUMP also indicates that something is wrong on the transfer (I can see proper traffic on the eth0 with good responses by Bind, but they do not reach their destination).

    named.conf (as originated using the named.conf.master of ISPCONFIG) is:

    options {
    pid-file "/var/run/bind/run/named.pid";
    directory "/etc/bind";
    auth-nxdomain no;
    /*
    * If there is a firewall between you and nameservers you want
    * to talk to, you might need to uncomment the query-source
    * directive below. 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;
    notify-source * port 53;
    transfer-source * port 53;
    //allow-query {any;};
    //forwarders {
    // 62.219.186.7;
    // 192.117.235.235;
    //};
    //allow-recursion {
    // 10.0.0.0/8;
    //};


    };

    //
    // a caching only nameserver config
    //
    zone "." {
    type hint;
    file "db.root";
    };

    zone "0.0.127.in-addr.arpa" {
    type master;
    file "db.local";
    };


    zone "mydomain.info" {
    type master;
    file "pri.mydomain.info";
    };



    //// MAKE MANUAL ENTRIES BELOW THIS LINE! ////


    IPTABLE -L looks like that (10.0.0.138 is the router/gateway, vanilla is the server with bind 9 = localhost):

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT tcp -- localhost.localdomain anywhere tcp flags:!FIN,SYN,RST,ACK/SYN
    ACCEPT udp -- localhost.localdomain anywhere
    ACCEPT tcp -- dnsdrp.bezeqint.net anywhere tcp flags:!FIN,SYN,RST,ACK/SYN
    ACCEPT udp -- dnsdrp.bezeqint.net anywhere
    ACCEPT all -- anywhere anywhere
    ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5
    DROP all -- anywhere 255.255.255.255
    DROP all -- anywhere 10.0.0.255
    DROP all -- BASE-ADDRESS.MCAST.NET/8 anywhere
    DROP all -- anywhere BASE-ADDRESS.MCAST.NET/8
    DROP all -- 255.255.255.255 anywhere
    DROP all -- anywhere 0.0.0.0
    DROP all -- anywhere anywhere state INVALID
    LSI all -f anywhere anywhere limit: avg 10/min burst 5
    INBOUND all -- anywhere anywhere
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere LOG level info prefix `Unknown Input'

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere LOG level info prefix `Unknown Forward'

    Chain OUTPUT (policy DROP)
    target prot opt source destination
    ACCEPT tcp -- vanilla.beacontech.info localhost.localdomain tcp dpt:domain
    ACCEPT udp -- vanilla.beacontech.info localhost.localdomain udp dpt:domain
    ACCEPT tcp -- vanilla.beacontech.info dnsdrp.bezeqint.net tcp dpt:domain
    ACCEPT udp -- vanilla.beacontech.info dnsdrp.bezeqint.net udp dpt:domain
    ACCEPT all -- anywhere anywhere
    DROP all -- BASE-ADDRESS.MCAST.NET/8 anywhere
    DROP all -- anywhere BASE-ADDRESS.MCAST.NET/8
    DROP all -- 255.255.255.255 anywhere
    DROP all -- anywhere 0.0.0.0
    DROP all -- anywhere anywhere state INVALID
    OUTBOUND all -- anywhere anywhere
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere LOG level info prefix `Unknown Output'
    ACCEPT tcp -- vanilla.beacontech.info 10.0.0.138 tcp dpt:domain
    ACCEPT udp -- vanilla.beacontech.info 10.0.0.138 udp dpt:domain

    Chain INBOUND (1 references)
    target prot opt source destination
    ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT tcp -- anywhere anywhere tcp dpt:www
    ACCEPT udp -- anywhere anywhere udp dpt:www
    ACCEPT tcp -- anywhere anywhere tcp dpt:https
    ACCEPT udp -- anywhere anywhere udp dpt:https
    ACCEPT tcp -- 10.0.0.0/8 anywhere tcp dpt:smtp
    ACCEPT udp -- 10.0.0.0/8 anywhere udp dpt:25
    ACCEPT tcp -- 10.0.0.0/8 anywhere tcp dpt:5900
    ACCEPT udp -- 10.0.0.0/8 anywhere udp dpt:5900
    ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
    ACCEPT udp -- anywhere anywhere udp dpt:ssh
    ACCEPT tcp -- anywhere anywhere tcp dpt:domain
    ACCEPT udp -- anywhere anywhere udp dpt:domain
    ACCEPT tcp -- 10.0.0.0/8 anywhere tcp dpt:81
    ACCEPT udp -- 10.0.0.0/8 anywhere udp dpt:81
    LSI all -- anywhere anywhere

    Chain LOG_FILTER (5 references)
    target prot opt source destination

    Chain LSI (2 references)
    target prot opt source destination
    LOG_FILTER all -- anywhere anywhere
    LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound '
    DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN
    LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound '
    DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST
    LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound '
    DROP icmp -- anywhere anywhere icmp echo-request
    LOG all -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound '
    DROP all -- anywhere anywhere

    Chain LSO (0 references)
    target prot opt source destination
    LOG_FILTER all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound '
    REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

    Chain OUTBOUND (1 references)
    target prot opt source destination
    ACCEPT icmp -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT all -- anywhere anywhere


    Any idea how to make it work? How to enable the highports on the IPTABLE to be processed right or alternatively how to channel all traffic via port 53?

    Thanks,
    YBZ
     
  2. falko

    falko Super Moderator

    Does it work when you switch off the firewall (for testing purposes)?
     
  3. ybz

    ybz New Member

    The plot thickens...

    Killing the firewall did not change a thing, but then I tried testing the situation from another clients on the same network and everything was working perfectly! So, I went back to my client (who used to work perfectly for the first network in a different location, with the same IP layout) and it was still not getting these DNS resolve answers.

    I checked the client firewall (on/off did not change the situation). Other services between this client and the server works well (SSH, VPN, etc.).

    Then I got to the /etc/resolv.conf of the client. It was pointing to the router as nameserver (as generated automatically by the network manager). This setting was working fine both in the previous network and in the current one when the router was set to automatically pick DNS servers when dialing up on the ADSL.
    But whenever I changed the router setting to look first into the network for the local DNS, the client stopped responding and I get these dozens of highport UDPs hits (on the firewall) from the DNS server.

    Only when I changed the /etc/resolv.conf to point out to the local DNS as main nameserver, I managed to resume normal work.

    So, the questions here are:
    1) Is that normal?
    2) Why it was working in 2 scenarios out of 3?
    3) Does all this make sense to you?

    Thanks,
    YBZ
     
  4. falko

    falko Super Moderator

    Seems as if this has something to do with your router. Do you use the same router model in both networks?
     
  5. ybz

    ybz New Member

    Well, Indeed it is not the same router model, but I'm not sure how this explains the different resolv.conf settings on the client and their consequences!
    Note that when the router in the new location was set to look for DNS outside the network, the original resolve.conf was working fine.
     

Share This Page