ConfigServer Community Forum

Hi Folks,

I have a WHM server running CSF that has an intermittent DNS problem.

Here are the symptoms.

..............
ping dns1.xxxxxx.com -t

Request timed out.
Request timed out.
Request timed out.
Reply from xxx.xxx.xxx.xxx: bytes=32 time=15ms TTL=57
Reply from xxx.xxx.xxx.xxx: bytes=32 time=16ms TTL=57
Request timed out.
Request timed out.
Request timed out.
Reply from xxx.xxx.xxx.xxx: bytes=32 time=16ms TTL=57
Reply from xxx.xxx.xxx.xxx: bytes=32 time=16ms TTL=57
Request timed out.
Request timed out.
Request timed out.
................
Ping statistics for xxx.xxx.xxx.xxx:
Packets: Sent = 2923, Received = 2055, Lost = 868 (29% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 363ms, Average = 28ms

However, when I add the IP address of my modem to the csf.allow, I get perfect results with no timeouts.

Which means CSF/LFD is somehow randomly blocking valid requests to my WHM DNS server...

What further details should I provide ?

CENTOS 5.10 i686 virtuozzo – server2
WHM 11.42.0 (build 23)
Load Averages: 0.57 0.80 1.00


Cheers,
Pete

Also, this is causing me huge problems with companies that need to ping my DNS to check email domains. Many emails are being rejected due to this bug/issue.

Is there any official support ? I had all my CSF firewalls installed by chirpy et al.

Those timeouts for ping most likely your settings for ICMP_*, alter them to suit your needs. No idea why you would be seeing DNS issues at all.

Tracert has the same issues, sometimes gets through, sometimes takes a few attempts.

How do I get this looked at by a professional ? It started only 3 or so weeks ago and is causing companies to move their DNS services away from me...

Its definitely CSF that is causing the timeouts, I am not sure how or why, but I am not sure what ICMP does in all of this..

How would I change the ICMP setting, and what will it help?

I wondered if it was just a load issue, but don't have the tech clout to work it all out.

Cheers,
Pete

OK - this looks like a potentially MASSIVE problem for CSF.

Chirpy, ----IF my hunch is right CSF, is going to be the cause of millions of undelivered emails to corporations using Microsofts FOFO services, because of the distributed and aggressive nature of the FOFO email validation checks.

I would be happy to be wrong, but here goes..

I have pasted below an email from a LARGE oil company tech, as they have been investigating WHY they were only intermittently receiving some of my clients emails.

The new Microsoft FOFO mail servers are playing havoc with our and potential everybody else CSF firewalls, because they do DNS checks on each email processed, from different locations globally, somehow swamping CSF (or triggering a short IP based BAN).

I have increased the ICMP settings from 1/s to 10/s and this seems to have stabilised the situation somewhat, but in my limited capacity, my gut feel is that FOFO is swamping our website server with SO MANY email dns validation requests, that CSF/LFD is banning it for 30 seconds or so every so often, causing a failure of validation, and therefore a rejected email.

This is serious.

------------------------
Hi customer,

Below is the investigation result from our end. Can I please request you to check at your end.

Analysis

To make it easier to understand the problem root cause, I would first like to share some background of the FOPE service. FOPE is a cloud service which has deployed multiple data center worldwide, as LARGECORPORATION.com has subscribed this cloud service, per running message trace, I find your emails will be routed via different FOPE data center like AM(Amsterdam), CH(Chicago),VA(Virginia), etc.

And once sending email from different Data Center, the DNS query request will be delivered via its related region network. And I just managed to do some back end DNS query test which I discover that from specific data center, eg. AM/VA, the recipient @customerwebsite.com.au’s DNS hosted provider dns1.helpwise.com.au’s response is pretty much delayed (delayed almost more than 30+ secs) this will lead to the DNS query failed error as FOPE cannot get any response from their DNS server in certain period. By the way, another proof to identify the network issue is that we even cannot successfully open the recipient’s public facing website http://customerwebsite.com.au/ in AM/VA location.

However, in other region like Singapore, we can get their DNS response pretty quick, which will not encounter the DNS query issue. (That can also explain why the public DNS query will not show any problems.)

From above troubleshooting, we can identify that the recipient DNS hosted provider our dnswebserver.com.au needs to investigate their networking issue with worldwide region like America and Holland to learn why it cannot respond in quick manner.

Also to help recipient side to narrow down the network routing, you can also share the FOPE outbound IP ranges for them, which will be the reference to let them examine the traffic from those worldwide region:

65.55.88.0/24
94.245.120.64/26
207.46.51.64/26
207.46.163.0/24
213.199.154.0/24
213.199.180.128/26
216.32.180.0/24
216.32.181.0/24


---------------------------
I have added those IP in the csf allow file, and removed all current deny addresses.. I await further instructions..

Cheers,
Pete

You are conflating separate issues here. DNS lookups are to port 53 over UDP (and sometimes TCP), not ICMP which is used for services such as PING. If the issue is solely with DNS lookups, then changing ICMP settings will have no effect.

Similarly, TRACEROUTE does not use ICMP, it uses UDP to ports 33434 to 33523.

As we have stated on our site, csf is provided as-is and we do not offer support for it directly. If you need help understanding iptables, how it is configured and how it affects traffic to and from your server, you would need to hire a suitable server administrator - this is not a service that we offer.

That said, in this case, if you have definitely identified iptables as the issue, you should ensure that none of the following options are enabled:

SYNFLOOD
LF_BIND
PORTFLOOD
CONNLIMIT
DNS_STRICT
DNS_STRICT_NS
CC_*

You should ensure that CT_LIMIT is set to a suitably high value to not produce false-positives.

Lastly, you should obviously ensure that port 53 is included in TCP_IN/TCP_OUT/UDP_IN/UDP_OUT

If you have whitelisted those ip address ranges, none of the above will be relevant as you are allowing the ip's through iptables without restriction.

I am not a networking expert, I hired you folks to install the CSF firewall on my server, its been running for years well, and thought it prudent to ask for help here, as this is a very new and seemingly CSF related issue.

My datacentre runs APF not CSF, I much prefer CSF and so installed it, but figured I would pay for support if/when needed. I didn't realise it wasn't available.

I assume by the answers I am getting that this is not a CSF bug, but a CSF setup issue?

So what part of the firewall would block an incoming IP address for 1 or 5 or 10 seconds ?

I have assumed it was the Microsoft Cloud servers hammering my firewall that may have caused CSF to think of it as something close to a flood 'attack'

I will look at the settings you have provided and see if I can make some sense of it, and appreciate your input.

I thought I would add my settings here:

CT_LIMIT = 300 (changed to 500)
SYNFLOOD = 0
LF_BIND = 0
PORTFLOOD = (empty) (Virtuozzo VPS)
CONNLIMIT = (empty) (Virtuozzo VPS)
DNS_STRICT = 0
DNS_STRICT_NS = 0
CC_* = All (empty) except CC_LOOKUPS = 1
TCP_IN/TCP_OUT/UDP_IN/UDP_OUT = '53' in all settings

Cheers,
Pete

It would seem that I'm also having this problem. When CSF kicks in and blocks, I can't even do an MX lookup from MXToolbox dawt com

Did you ever find a resolution?