Need assistance in determining next step in troubleshooting

HaroldSch · 03-25-2022, 04:50 AM

I am unclear as to how to begin to troubleshoot an issue I am seeing under Slackware 15.0 x64.

I use a dedicated PC to provide IP Forwarding, DHCPD and Firewall services for my home. All communications with the outside world go through this PC. Lets call this PC#1. PC#1 has Slackware 14.2 x64 installed on it with all of the latest updates. I have a second PC, identical hardware as PC#1, that has Slackware 15.0 x64 installed on it again with all of the latest updates. Lets call this PC#2.

My child uses Google classroom to participate in online school. With PC#1 connected to my network, normal two-way video and audio communications between the teacher and my child are possible. When I replace PC#1 with PC#2, the video that is generated locally does not make it to the teacher. The teacher sees a blank screen. My child is able to see video received from the teacher. Audio continues to behave normally, that is the teacher and my child are able to communicate verbally.

For PC#1 and PC#2 I am able to use identical initialization scripts, except for rc.inet1.conf which has updated formatting. For the Firewall services, I utilize Shorewall with the same scipts for both PC's.

If anyone is able to provide some insight as to a next step in troubleshooting, I'd greatly appreciate it!

Thank you.

Ser Olmy · 03-25-2022, 10:28 AM

I'll bet this is a NAT helper issue.

If you're still running the stock Slackware 4.4.x kernel on the 14.2 system, the NAT helpers are automatically bound. All you need to do is load the modules, and the traffic will be covered by any RELATED rule.

I don't know exactly in which kernel version this was changed; I believe it was around 4.7. I remember having to modify my firewall script because FTP stopped working.

Anyway, as 15.0 uses a much more recent kernel, NAT helpers simply won't work automatically. Protocol helpers have to be specified explicitly by firewall rules in order for "RELATED" traffic to be correctly identified and handled.

Try manually adding conntrack ("-j CT") rules for the relevant protocols to the PREROUTING chain of the raw table. For video conferencing this is likely to be H.323 or SIP:

Code:

iptables -t raw -I PREROUTING 1 -p udp --dport 1719 -j CT --helper RAS
iptables -t raw -I PREROUTING 2 -p tcp --dport 1720 -j CT --helper Q.931
iptables -t raw -I PREROUTING 3 -p udp --dport 5060 -j CT --helper sip

This should work even if you already have an active ShoreWall ruleset. Also, make sure the nf_nat_323 and nf_nat_sip modules are are loaded.

dodoLQ · 03-27-2022, 05:09 AM

Quote:

Originally Posted by Ser Olmy

I don't know exactly in which kernel version this was changed; I believe it was around 4.7. I remember having to modify my firewall script because FTP stopped working.

Can you post an example of iptable rules for doing FTP? I've a same pb here since switching to 15.0.. Thanks.

Ser Olmy · 03-27-2022, 05:26 AM

Quote:

Originally Posted by dodoLQ

Can you post an example of iptable rules for doing FTP?

The FTP control channel uses TCP/21, and the helper module is simply called "ftp":

Code:

iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp

HaroldSch · 03-27-2022, 05:55 AM

Thank you so much for your input.

I can confirm that Ser Olmy's assessment is correct. It's definitely missing NAT Helper's. The issue seems to be with shorewall's initialization after first install.

Using 'shorewall show capabilities' under Slackware 14.2 x64 produces a list of available kernel/iptables capabilities. Under 15.0 x64 I would get an error message and no list. After some testing, I was able to get a valid list of available kernel/iptables capabilities under 15.0 x64 but at this moment I am unable to clearly define why. I will continue my testing and get back to you.

Ser Olmy · 03-27-2022, 06:25 AM

A small clarification: While NAT is almost certainly involved in your scenario, you'd actually have issues even in cases where no NAT was being performed.

The problem is a lack of protocol-specific connection tracking in the firewall, also known as Application Level Gateways (ALGs). These software modules inspect network traffic on the application level, and will dynamically create and destroy firewall rules to allow related traffic, such as an FTP data connection or a SIP RTP session.

These ALGs may also perform NAT-related tasks, such as altering references to IP addresses and ports. In the Linux kernel, the connection tracking modules are separate from the NAT modules, but the latter depends on the former.

HaroldSch · 03-27-2022, 08:16 AM

Thank you for the clarification! This is starting to make sense now.

When I woke up this morning and checked my 14.2 x64 box with the command 'shorewall show capabilities' I received the error message "ERROR: Chain 'capabilities' is not recognized by /usr/sbin/iptables." This is the same message I received on my 15.0 x64 installation. When there was no requirement to handle any special protocols, the chain did not exist.

Under 15.0 x64, if I don't start shorewall upon bootup, I can get a valid response for 'shorewall show capabilities'. Starting shorewall after receiving the valid response and doing a video test however still does not give me video. The connection tracking modules are loaded. 'lsmod' displays them.

HaroldSch · 03-27-2022, 08:54 AM

Update

'lsmod' lists the connection tracking modules that are loaded. Between the two boxes I'm not seeing an obvious difference/omission.
'shorewall show capabilities' displays my kernel/iptables capabilities. The 5.15.27 Kernel has more capabilities but again I'm not seeing any obvious omissions.

Yet for some reason under Slackware 15.0 x64 the connection tracking modules + shorewall are dropping video packets. I'm trying to create a log of this but a lot of information is generated in a very short period of time.

dodoLQ · 03-30-2022, 11:41 AM

Quote:

Originally Posted by Ser Olmy

Code:

iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp

Hi Ser Olmy

Can you adapt these rules please (i'm totally noob in iptables /o\)? Thank you.

Code:

iptables -A INPUT -i eth0 --protocol tcp --source-port 21 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --destination-port 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 --protocol tcp --source-port 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --destination-port 20 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 --protocol tcp --source-port 1024:65535 --destination-port 1024:65535 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --source-port 1024:65535 --destination-port 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT

HaroldSch · 03-31-2022, 05:02 AM

Update:

So I changed the rc.firewall script to the follow:

/sbin/modprobe ipt_MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Essentially making a simple router out of the PC#2.

The results were the same. Google Meet video is lost through the box. So that tells me shorewall is not the cause.

My guess is it's the kernel that's causing this. Time to do some more research.

Ser Olmy · 03-31-2022, 06:04 AM

Quote:

Originally Posted by HaroldSch

My guess is it's the kernel that's causing this. Time to do some more research.

Yes, that's what I said in my first reply.

You need to make sure the relevant "conntrack" and "NAT" modules are loaded, AND either create firewall rules in the "raw" table to activate connection tracking (and NAT helpers) for the relevant protocols, OR specifically re-enable the old behaviour where conntrack helper modules are enabled by default:

Code:

echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper

dodoLQ · 04-30-2022, 04:14 AM

Hehe

Code:

iptables -A INPUT -i eth0 --protocol tcp --source-port 21 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --destination-port 21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 --protocol tcp --source-port 20 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --destination-port 20 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 --protocol tcp --source-port 1024:65535 --destination-port 1024:65535 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --source-port 1024:65535 --destination-port 1024:65535 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT