Deactivation of Conntrack Helpers: Impact and configuration

What are conntrack Helpers?

Conntrack helpers are Linux kernel modules that facilitate the management of connections using dynamic ports, such as FTP, SIP, PPTP, among others. These modules extend the connection tracking system, known as conntrack, allowing certain protocols to operate correctly even when conventional packet filtering would not suffice.

The conntrack system allows the Linux kernel to track active network connections. Every time a packet enters or leaves the system, conntrack attempts to associate it with an existing connection or, if none exists, creates a new record. This is crucial for modern firewalls based on nftables or iptables, as it enables them to decide whether to allow or block packets based on the connection’s state.

Risks and deactivation of conntrack Helpers

However, despite their usefulness, conntrack helpers can pose a security risk. They can be exploited to open random ports without the system administrator’s knowledge, allowing unauthorized traffic, disguising malicious connections as legitimate, or even bypassing firewall rules to enable incoming connections that would normally be blocked.

Due to these risks, recent versions of the Linux kernel have disabled the autoloading of helpers by default, and starting with the 6.x series, this functionality has been completely removed.

This change directly impacts servers, especially those services that depended on these helpers, as they may cease functioning after a kernel update. It is not enough to merely open the ports manually in the firewall, since many of these protocols require the software to use a specific port range. To continue using these services, it will be necessary to manually configure the port range in the corresponding software and allow that range in the firewall to ensure proper connectivity.

Below, we explain which protocols and services are affected by this change and what adjustments you need to make both on the server and in the firewall profile.

Affected Protocols and Services by the deactivation

The following protocols and services depend on conntrack helpers and, in their absence, will require manual configuration.

• FTP (TCP/21): In passive mode, the server will assign a random port for data transfer and the client will attempt to connect, but without conntrack, the firewall will block the connection if those ports are not allowed.
  
  • Affected services: vsftpd, ProFTPD, Pure-FTPd, FileZilla Server, Microsoft IIS FTP Server, Serv-U FTP Server.
• TFTP (UDP/69): TFTP uses a single port (69) to initiate transfers, but data is sent through dynamic ports chosen by the server. Without conntrack, these responses may be blocked.
  
  • Affected services: tftpd-hpa, atftpd, dnsmasq (when used as a TFTP server), OpenTFTP.
• SIP (UDP/TCP 5060/5061): SIP handles call signaling, but the audio and video streams (RTP) are negotiated on dynamic ports. Without conntrack, these packets may be blocked, resulting in calls without audio or connection failures.
  
  • Affected services: Asterisk, FreePBX, Kamailio, OpenSIPS, Cisco CallManager, 3CX, Linphone, Ekiga, Zoiper, Grandstream PBX.
• H.323 (TCP/1720 and dynamic ports): Similar to SIP, this video conferencing protocol uses port 1720 for signaling, but requires dynamic ports for media traffic (audio/video). Without conntrack, these may be blocked.
  
  • Affected services: Polycom, Cisco Unified Communications, Avaya, Ekiga, Linphone, Microsoft Skype for Business, Google Meet (when using H.323 gateways).
• PPTP (TCP/1723 and GRE protocol 47): PPTP uses TCP/1723 for connection authentication and control, but data traffic is carried via GRE (protocol 47). Without conntrack, GRE packets may be blocked, preventing the VPN connection.
  
  • Affected services: Microsoft Windows VPN Server, MikroTik PPTP Server, SoftEther VPN, Cisco PPTP, OpenVPN (when used in PPTP mode).
• IRC - DCC (UDP/1024-65535): Direct Client-to-Client (DCC) connections in IRC allow file transfers and direct connections between users. Without conntrack, the random ports used in these connections may be blocked.
  
  • Affected services: UnrealIRCd, InspIRCd, ircd-hybrid, WeeChat, HexChat, mIRC, Kiwi IRC.

Manual Configuration

Below, we present the essential ports that must be manually opened in the firewall profile to ensure the proper functioning of each service:

Alternatives and Best Practices

To ensure the proper functioning of certain protocols without relying on conntrack helpers, it is necessary to manually configure port ranges and adjust firewalls. In the case of FTP, using passive mode with a fixed port range is recommended, although alternatives such as SFTP or WebDAV over HTTPS offer greater security and easier management. TFTP, by using dynamic ports, requires a similar configuration, but it is preferable to opt for more secure methods such as SFTP or HTTPS.

Real-time communication protocols such as SIP and H.323 require the definition of fixed ports for media transmission and the use of STUN/TURN servers to avoid blocks on NAT networks. Despite these configurations, solutions like WebRTC prove more practical and eliminate the need for complex setups. In the case of PPTP, it is crucial to allow GRE traffic through the firewall, although this protocol is now obsolete and it is recommended to replace it with more secure options such as WireGuard or OpenVPN.

For DCC connections in IRC, it is necessary to establish a fixed port range and open those ports in the firewall, in addition to using bouncers like ZNC to facilitate the connection. Alternatives such as XMPP with Jingle File Transfer or Matrix with an IRC bridge can replace DCC without the complications arising from dynamic ports.

In general, the best strategy to operate without conntrack helpers is to establish more predictable network configurations and, whenever possible, opt for modern technologies that reduce reliance on manual firewall settings.

Conclusion

Disabling conntrack helpers improves security by avoiding unnecessary packet processing and reducing the risk of attacks. However, this requires manual adjustments to ensure that certain services continue to function.

By following the configurations recommended in our web interface, it is possible to maintain a more secure firewall without compromising compatibility with essential services.

We hope this article has been helpful. If you have any questions about this or any other topic related to your Clouding servers, please do not hesitate to contact us at soporte@clouding.io. We’re here to help! 😉