Need assistance in determining next step in troubleshooting - PC utilized as firewall/ip forwarding
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. |
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 |
Quote:
|
Quote:
Code:
iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp |
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. |
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. |
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. |
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. |
Quote:
Code:
iptables -A INPUT -i eth0 --protocol tcp --source-port 21 -m state --state ESTABLISHED -j ACCEPT |
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. |
Quote:
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 |
Now mc works with ftp & iptables
Hehe :p
Code:
iptables -A INPUT -i eth0 --protocol tcp --source-port 21 -m state --state ESTABLISHED -j ACCEPT |
All times are GMT -5. The time now is 11:43 PM. |