From Bugzilla Helper:
User-Agent: Opera/6.1 (Linux 2.4.18-29Oct2002 i686; U)  [en]

Description of problem:
The 'high' security firewall set up by Lokkit does not let DNS replies or NTP replies through, contrary to what it says in the manual. This bug states the problem and suggested solution.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Set up a firewall with 'high' security
2.Dial up to internet using kppp dialler
3.Attempt to access web sites by domain name e.g. www.redhat.com. Also attempt to set time using 'ntpd -qA'.
	

Actual Results:  When connected to the internet using 'kppp dialler', all accesses to named domains (e.g. www.redhat.com) fail, because DNS replies are rejected by the firewall. Also, setting the time using 'ntpd -qA' does not work, because the responses from time servers are similarly rejected. 

Expected Results:  DNS replies should not have been blocked. This behaviour is contrary to what is stated on page 57 of the Red Hat Linux Installation Guide, which indicates that DNS replies should be allowed through.

Additional info:

The problem does not occur when connected using the Red Hat dialler, because a workaround has been provided in script 'ifup-post'. However this workaround is not effective for other diallers, which users may wish to use.

Users can let DNS and NTP replies through by using Lokkit's 'customise' feature to add the relevant ports, but this is potentially insecure because it lets too much else through.

I believe the correct solution would be for Lokkit, by default, to insert the following three lines (or similar) into the iptables configuration it generates in '/etc/sysconfig/iptables' (please remove any unwanted line wrapping):

  -A RH-Lokkit-0-50-INPUT -p ! udp -j ACCEPT
  
  -A RH-Lokkit-0-50-INPUT -p udp -m udp --sport 53 --dport 1025:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT
  
  -A RH-Lokkit-0-50-INPUT -p udp -m udp --sport 123 --dport 123 -m state --state RELATED,ESTABLISHED -j ACCEPT
  
Explanation: the first of the above lines is simply an optimisation, to bypass possibly time-consuming checks for non-udp packets.

The second accepts DNS replies for a 'related' or 'established' connection.

The third accepts NTP replies from time servers, similarly.