ConfigServer Community Forum

Dear all,

I am note sure if anyone have issue with MTU after the new version of CSF?
If i active csf by command csf -e, and if i use MTU website to check the IP MTU, it drops to 1496.
But if i instantly disable it by csf -x., It goes back to 1500.
This MTU problem affects my server connection.

I am able to solve this problem by disableing the "packet filter" on one of my cpanel server, but not on all of my server

Do you have any sguggestion to solve this problem?

Thanks.
Daniel

Yes, we've just been looking at a connectivity issue one customer has to a server running CSF and came to the conclusion it was an MTU issue. We're seeing it drop down to 1481 on several servers.

Largest responses to tests:

CSF enabled:

35 44.826188344 <host_tested> -> 141.138.203.105 ICMP 1495 Echo (ping) reply id=0x4b45, seq=1/256, ttl=64 (request in 34)

1481 MTU in effect, 14 bytes are for ethernet.

CSF disabled:

18 0.269080556 <host_tested> -> 141.138.203.105 ICMP 1514 Echo (ping) reply id=0xce45, seq=1/256, ttl=64 (request in 17)

1500 byte MTU allowing for 14 bytes of ethernet

It only happens under certain conditions though, as I can test from a different host and it makes no difference if CSF is enabled or not, a 1514 reply goes back. This is affecting some users though.

This is related to: viewtopic.php?f=6&t=10378

We, and others, are seeing issues where CSF appears to incorrectly limit the MTU under certain circumstances. We're seeing this with a user making use of a VPN service. We're seeing this over multiple servers running CSF, be they virtual or physical, CentOS6 or 7.

Version Interface: Largest responses to tests:

CSF enabled:
1481 MTU in effect, 14 bytes are for ethernet.

CSF disabled:
1500 byte MTU allowing for 14 bytes of ethernet

It only happens under certain conditions though, as I can test from a different host and it makes no difference if CSF is enabled or not, a 1514 reply goes back.

I can't say 100% when this started happening, as the user having issues was only moved to this server (previous server still had APF) in the last couple of days. Based on the thread in general it started on or before 26th July.

Thanks.

Bugs are issues with the csf, lfd or UI scripts, this is not. This is an iptables rules issue relating to your server, kernel and network. As such, you would need to go through your iptables rules to determine where the issue might be.

Depending on how you are determining the MTU (apart from the actual value set on the NIC), there are some obvious settings in csf that you should check:

1. Ensure you are not filtering any ICMP traffic: ICMP_IN, ICMP_OUT and IPV6_ICMP_STRICT should all be set to "0"

2. SYNFLOOD should not be enabled

3. PACKET_FILTER should not be enabled

4. If you still see problems, try disabling the SPI configuration and use a static one by setting LF_SPI to "0"

Always restart csf and then lfd after making any changes.

Other than those, it's a matter for you to go through iptables chains and rules to determine where the issue you are seeing may be.

Regarding dates, nothing has changed in iptables rule configuration in csf since May when DROP_OUT was added and set to REJECT by default. You can set that to DROP to replicate rules before then.

We have done testing with MTU and found no issues at all between servers on a variety of networks, datacenters, countries and OS's.