#1  
Old 30th October 2009, 16:03
ybz ybz is offline
Junior Member
 
Join Date: Oct 2009
Posts: 10
Thanks: 2
Thanked 0 Times in 0 Posts
Default Bind / IPTABLES issue

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
Reply With Quote
Sponsored Links
  #2  
Old 31st October 2009, 13:27
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,740 Times in 2,575 Posts
Default

Does it work when you switch off the firewall (for testing purposes)?
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #3  
Old 1st November 2009, 15:53
ybz ybz is offline
Junior Member
 
Join Date: Oct 2009
Posts: 10
Thanks: 2
Thanked 0 Times in 0 Posts
Default

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
Reply With Quote
  #4  
Old 2nd November 2009, 13:19
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,740 Times in 2,575 Posts
Default

Seems as if this has something to do with your router. Do you use the same router model in both networks?
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #5  
Old 2nd November 2009, 13:22
ybz ybz is offline
Junior Member
 
Join Date: Oct 2009
Posts: 10
Thanks: 2
Thanked 0 Times in 0 Posts
 
Default

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.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Permission Denied Bind Slave Server Problems wxman Server Operation 17 22nd March 2014 12:30
IPtables rule to let PPTP access LAN brianwebb01 Installation/Configuration 0 1st May 2008 21:23
ISPConfig and BIND on Debian sarge (rfc1912 : failed on zonecheck) arnaud Installation/Configuration 13 6th March 2007 12:40
iptables issue with xen perfect setup - debian alexnz HOWTO-Related Questions 3 25th November 2006 13:49
Bind-Chroot-Howto (Debian) spaz HOWTO-Related Questions 5 9th March 2006 14:50


All times are GMT +2. The time now is 13:06.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.