Help to create a firewalld rule to allow connection between a program and service

Hello,

This is on CentOS 7.7 x86_64.

I have a program that need to connect to a service. The program runs fine with firewalld turned off but I get an error about not being able to connect to the service with the firewall on.

As far as I can tell, the service was set up to accept connections at 192.168.10.27 port 10731. My understanding is that the program uses multicast to 239.255.219.183:10731 to find the service.

If I run sudo ss -lnpAinet, I get the 2 entries for the service,

Netid  State   Recv-Q Send-Q Local Address:Port            Peer Address:Port              
udp    UNCONN  0      0      239.255.219.183:10731         *:*      users:(("MyServer64",pid=10225,fd=26))
tcp    LISTEN  0      128    [::ffff:192.168.10.27]:10731  [::]:*   users:(("MyServer64",pid=10225,fd=27))

I can't even seem to find logfiles to show the connection being blocked. That would be a big help in determining what I need to allow. I have very little experience with firewalld so I need some help to determine what is being blocked and how to configure a rule to allow it.

Thanks,

LMHmedchem

Hello,

You can add a trusted zone with specific nic, it's allow all trafic in that netowrk.

ChatGPT 4o Replies to Your Question @LMHmedchem

To resolve the issue of your program being blocked by firewalld on CentOS 7.7 while connecting to a service via multicast and TCP, you'll need to configure firewalld to allow both the UDP multicast traffic and the TCP connection on the required port. Below is a step-by-step guide on how to identify the blockage and configure the firewall accordingly:

1. Identify the Current Firewall Rules

First, check your current firewall rules using the following command:

sudo firewall-cmd --list-all

This will show the active zones, interfaces, services, and allowed ports. Look for any rule that might already exist for your service.

2. Open the TCP Port

Since your service is listening on 192.168.10.27:10731 for TCP connections, you'll need to allow this port in firewalld:

sudo firewall-cmd --zone=public --add-port=10731/tcp --permanent

If your network interface is in a different zone (e.g., trusted, internal), make sure to adjust the --zone option accordingly. Use sudo firewall-cmd --get-active-zones to check your active zones.

Reload the firewall for the changes to take effect:

sudo firewall-cmd --reload

3. Allow Multicast Traffic

For multicast traffic, you need to ensure that your firewall allows incoming UDP packets destined for 239.255.219.183:10731. Here's how to do that:

  • Add a rule to allow multicast UDP traffic on the specific port (10731):

    sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="239.255.219.183" port protocol="udp" port="10731" accept' --permanent
    
  • Allow multicast traffic more generally (optional, if needed):

    sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" destination address="239.0.0.0/8" accept' --permanent
    

This ensures that multicast traffic on the specified port and address is allowed.

4. Check for Blocked Packets in Logs

To see if firewalld is blocking any traffic, you can enable logging for dropped packets:

sudo firewall-cmd --set-log-denied=all
sudo firewall-cmd --reload

Once enabled, check the logs for any dropped packets. You can view the logs in /var/log/messages or /var/log/firewalld. To search for denied packets related to your service, use:

grep 'DENIED' /var/log/messages

Look for anything related to port 10731 or multicast addresses (239.x.x.x).

5. Test Connectivity

After making the changes, try running your program again and see if it can connect to the service with firewalld enabled. You can verify the firewall status with:

sudo firewall-cmd --list-all

This will show the open ports and services, ensuring that your configurations are applied.

6. Revert Logging (Optional)

Once you're done troubleshooting and the connection works as expected, you can turn off denied packet logging to avoid excessive log entries:

sudo firewall-cmd --set-log-denied=off
sudo firewall-cmd --reload

Summary of Commands:

# Add TCP rule for port 10731
sudo firewall-cmd --zone=public --add-port=10731/tcp --permanent

# Add UDP multicast rule for 239.255.219.183:10731
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="239.255.219.183" port protocol="udp" port="10731" accept' --permanent

# Reload firewall to apply changes
sudo firewall-cmd --reload

# Enable logging for denied packets (optional)
sudo firewall-cmd --set-log-denied=all
sudo firewall-cmd --reload

# Check logs for denied packets
grep 'DENIED' /var/log/messages

By following these steps, your application should be able to connect to the service even with firewalld enabled.'

Note: ChatGPT can make mistakes. Check important info.

The only think I can add to this, is that I rarely use sudo for every command when working like this, and just work as the superuser via sudo -i regardless of any social pressure otherwise. It's up to you how you work as superuser based on the risk management profile of your system. Obviously working on a production system where a mistake can cause a major outage and large financially loses is different than on a VPS you are learning on, etc (and of course company policies toward superuser usage).