Hello McAfee Forum,
I require a second opinion and some insight on this issue I am experiencing.
When running the nslookup command against a DNS server, I am getting intermittent timeouts.
Communication from source to destination go through our Sidwinder.
I checked the logs on the sidewinder with acat and see logs for successful lookups. However, for lookups that timeout, I don't see any evidence of the connection from the live logs (using acat -ake "src_ip xxxx").
I checked the dashboard on our sidewinder and can see the following under "packet filter sessions".
Protocol : TCP
Session count: 185
Maximum Sessions: 2500
Session count: 2500
Maximum Sessions: 2500
I believe the timeouts of the nslookup could be related to the fact that UDP packet filter sessions are maxed out. Do you happen to know what the common causes of this are?
Also, what is the recommended maximum sessions configuration? Should I be increasing the maximum sessions or would this cause resource issues.
I think you have found the exact cause of your DNS problems. While I don't have the data to prove what is happening, my guess is that DNS traffic is using up all the sessions.
There are a couple of reasons why you may have alot of open UDP sessions:
1) UDP has no such thing as a reset, or way to force the session to close. therefore the only way that UDP sessions will be removed from the firewall is by timing out.
2) The UDP timeout is typically higher than is necessary, especially for DNS traffic. Remember that if a DNS server does not respond in 5 seconds or so (hopefully it responds a lot sooner, less that 1 second), the DNS query probably failed. The default idle timeouts may be 5 minutes, or even up to an hour.
The main resource that TCP/UDP packet filter sessions use is memory. Since most of our appliances nowadays have a ton of memory, increasing the session limit is not a problem. If you have a smaller appliance, you could probably still increase the limit to 50000 to 100000 and have no issues at all.
So, my recommendation is to lower the idle timeouts, and increase the session limit.
I pulled up the 2100F specs and it looks like it has 2 or 3 GB of memory. While this is on the lower end, you should be able to significantly increase the expected connections. The problem with giving you max session numbers is that it depends on many other variables, including what other type of traffic you are passing. If you are also using proxies, sendmail, virus scanning, etc, the max sessions that the firewall can handle would be lower.
I'm showing that in our controlled test lab the 2100F could handle 1 million sessions (so combined I would make sure TCP and UDP do not exceed that to be safe).
Do you know how many sessions you will need to pass at any given time?
Matt, thanks loads for the prompt reply, much appreciated. I understand the caveat around configuration variables. Regarding our potential max connections I'm afraid I don't know how many we'll potentially need. Do you know if it's possible to view the concurrent packet filter sessions via SNMP (or see a log entry each time a connection is rejected), I've looked through the SCC MIBs but can't see anything?
I'm already monitoring memory usage so will increase both TCP and UDP to 10k sessions as a first step and monitor memory utilisation.
I wrote an article awhile back that should accompish this. You could tweak the alert to send snmp traps as well:
If you want to see the current usage, you can use the command 'ipfilter -vO'.
Matt, I've increased the max filter sessions to 10k and all looks well. Presumably if I wanted a trap at 75% utilisation I would use:
cf audit add filter name='ipfilter session limit' filter_type=system number=2500 sacap_filter='type AUDIT_T_ERROR and facility f_kernel_ipfilter'
Is it possible to specify text in the trap, when I tested it I received a generic trap ("user defined" I think was the MIB info) that didn't point to the trap trigger?
That is a good thought, but unfortunately not how it works. The alarm that you can configure only lets you know when you have run out of sessions. There is no way to be alerted before that point. The "number" is actually specifying the trap oid that will be sent. If you look at the product guide, there is a section for snmp that might help. There are about 30 trap oids that can be used, some of them are user defined (but unfortunately you cannot change the text in the trap).
Hope this helps,