[ScreenOS] DNS reply packet is dropped thru the firewall. How is DNS traffic handled?
SUMMARY:
By default, DNS traffic, running on UDP port 53, is handled with the ALG (Application Layer Gateway) feature on the firewall. Therefore, a DNS session is aged out differently compared to a normal UDP session. However, on high-end firewall models, a session of DNS traffic is controlled as a hardware session, resulting in different aging-out behavior. This article addresses an issue with the firewall dropping DNS Reply packets with two scenarios: a small/medium model and a high-end model.
PROBLEM OR GOAL:
DMZ Zone Untrust Zone
[Internal DNS Server]------------[Firewall]---------------[External DNS Server]
(src.port = a fixed one) (dst.port = 53)
Internal DNS server is on DMZ network
The internal server sends DNS queries to an external DNS server located on Untrust side of the Juniper firewall
Internal DNS server sends DNS requests using the same source port for all queries.
A policy exists from DMZ to Untrust permitting service DNS.
DNS query response (reply) packet is sometimes dropped
SOLUTION:
Scenario-1 - The firewall is a SSG firewall, NS-500, NS-200, NS-50/25, or NS-5GT.
The default behavior on the Juniper firewall is to close a DNS-related session as soon as a DNS reply matching that session is received.
Here's a scenario where DNS Reply packets are dropped:
A session for DNS traffic is created when the first DNS query packet hits the firewall and there is a permitting policy configured. The default timeout is 60 sec.
Immediately before the session is closed, a new DNS query is transmitted, and since it matches an existing session (since source and destination port/IP pair is always the same), it is forwarded by the firewall. Note that the session timeout is not refreshed according to any newly arriving packet.
The created DNS session is aged out when the first DNS query response (reply) hits the device, regardless how much the timeout remains.
When a DNS reply is passed through the firewall, the session is aged out.
All subsequent DNS replies are dropped by the firewall, since no session exists.
To have a DNS session opened as long as the specific DNS service timeout, disable the ALG feature for DNS traffic with EITHER method described below.
1. Disable the ALG DNS globally on the firewall. (This is available on ScreenOS 6.0.0 and above.)
unset alg dns enable
OR
2. Disable the DNS ALG on a policy, by configuring the policy to permit only the DNS service with an option 'application ignore'.
set policy id 100 top from dmz to untrust dns_internal dns_external dns permit
set policy id 100 application ignore
Scenario-2 - The firewall is a high-end model (ISG-1000, ISG-2000, NS-5000 series) which utilizes hardware sessions.
On the high-end models, the DNS session is a hardware session, so the behavior is different than Scenario-1.
Here's another scenario where the DNS Reply packets are dropped:
A session for DNS traffic is created when the first DNS query packet hits the firewall and there is a permitting policy configured. Since it is a hardware session it has a default timeout of 8 seconds.
Because the session is not controlled by the CPU, the ALG feature does not affect the DNS hardware session in this scenario. (The DNS session is NOT aged out due to the first DNS reply packet.)
The session timeout is always refreshed by a newly arriving packet, either DNS query or DNS reply.
A DNS reply packet may be dropped if the DNS server takes a longer time than the DNS hardware session timeout to respond to a received DNS query.
When the ALG DNS is disabled, the DNS hardware session timeout depends on the service DNS timeout. Therefore, the solution for this scenario is as the follows:
1. Disable ALG DNS as stated in Scenario-1 above.
AND
2. Configure the service DNS timeout with a proper value for your environment.
set service dns timeout N
Link to doc:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB12312&actp=RSS