Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 2459 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

need help with dns

Toto
hi @all

thats my prob .. see log for detail:


2004-Jan 28 14:46:13 (none) kernel: UDP Drop: IN=eth0 OUT=eth1 SRC=xxx.xxx.0.16 DST=xxx.xxx.100.89 LEN=223 TOS=0x00 PREC=0x00 TTL=63 ID=21974 DF PROTO=UDP SPT=53 DPT=48823 LEN=203 
2004-Jan 28 14:46:15 (none) kernel: UDP Drop: IN=eth0 OUT=eth1 SRC=xxx.xxx.0.16 DST=xxx.xxx.100.89 LEN=223 TOS=0x00 PREC=0x00 TTL=63 ID=21977 DF PROTO=UDP SPT=53 DPT=54330 LEN=203

eth0 network is internal net and eth1 is dmz
so how must the rule setup, to pass dns service trough 

my rule for now:

eth0 network  -> dns -> eth1 network -> allow
 
the ip 0.16  is the  nameserver and the 100.89 ip request nameservice from 0.16 the firewall is also a forwarder to my isp nameserver.

hints ? 
  


This thread was automatically locked due to age.
Parents
  • 0
    if ip 0.16 is the namserver and 100.89 the requesting client, your rule should be:
    100.89 -> dns -> 0.16 -> allow
    or more general
    eth1network -> dns -> eth0network -> allow  (not recommended of course!) 

    in your logs you see that all answers form your dns (0.16) to the client (100.89) are blocked. 

    greets,

    gnjb   

    ps: you should think about setting up split dns. so no "external" (or dmz) machine needs access to internal network.
  • 0 in reply to gnujuba
    i made a rule like that... but the result is like my first post  [:(]

    more hints ?  
  • 0 in reply to Toto
    The rule: TCP, UDP, or TCP+UDP??
      
  • 0 in reply to SecApp
    [ QUOTE ]
    The rule: TCP, UDP, or TCP+UDP??
       

    [/ QUOTE ]

    like astaro did in setup, static dns tcp+udp...  
  • 0 in reply to Toto
    This is a fuzzy area of rules that I welcome others to comment on. A stateful UDP rule should permit the DNS server's response packets to return within a set time interval, seeing as how UDP packets went out. To make this work for now, add another rule that permits DNS from the DNS to the Internal LAN for now.
        
  • 0 in reply to SecApp
    i thought it works like that (statefull).

    our internal dcs have a forwarder to our dns server in the dmz.
    and only dns is allowed (tcp/udp source 1:65535 dst 53).

    and it works. 

    how does iptables simulate "statefull inspection" for udp ?

    greets,

    gnjb   
Reply
  • 0 in reply to SecApp
    i thought it works like that (statefull).

    our internal dcs have a forwarder to our dns server in the dmz.
    and only dns is allowed (tcp/udp source 1:65535 dst 53).

    and it works. 

    how does iptables simulate "statefull inspection" for udp ?

    greets,

    gnjb   
Children
  • 0 in reply to gnujuba
    I'm not sure how iptables does it; which is why I asked. When you have a directional UDP firewall rule, many stateful firewalls allow the first packet outbound, then subsequent packets inbound to the same IP that initiated the outbound for a limited time period.

    DNS prefers to use UDP to do its work...
      
  • 0 in reply to SecApp
    I think I am having a similar problem.

    the return DNS UDP packets are being blocked. Even with a rule allowing them.

    My DNS server is inside my network (just red and green here) and I have a NAT rule in place to forward DPT=53 to it.  
    All my internal clients use it for DNS. 
    DNS Proxy is disabled.

    In my Logs I see this frequently

    2004-Jan 29 09:08:03 (none) kernel: UDP Drop: IN=eth1 OUT=  SRC=xx.xx.49.58 DST=xx.xx.83.109 LEN=76 TOS=0x00 PREC=0x00 TTL=48 ID=46356 PROTO=UDP SPT=53 DPT=40229 LEN=56 

    I have two filter rules that should be allowing this particular one through. (Actually.. I wouldn't think I need them at all).

    I allow all from the SRC IP.
    I have another rule that allows all UDP with SPT=53.

    Yet I still get the packets dropped.   
  • 0 in reply to Rob_F
    The SPT is not important; what is important (apparently for UDP?) is to have a separate rule for each direction, DPT 53...
      
  • 0 in reply to SecApp
    ?? but the SPT is important.

    Those are the packets being blocked/dropped.

    Strangely, a rule doesn't solve the problem.

    I suspect that this is a problem with the stateful inspection and that its dropped prior to reaching the packet filter chain.