On 15.01.2023 08:26, Marc Chamberlin wrote: ...
Well, if this is the only way you can do it ... Andrei - The equivalent command line, for what I did to open the ports that I knock on, is this -
nova:/srv/firewall # firewall-cmd --add-port=xxxx/tcp --add-port=yyyy/tcp --add-port=zzzz/tcp --zone=internal success
No matter whether I use the GUI or the command line, to open these ports I use to knock on, it makes no difference. The port knock daemon is not seeing the knocks that occur on these ports, and therefore not inserting a rule into the ip tables for actually opening the service port that I want it to do, when given the right knock sequence.
I used the firewall-config GUI, selected my internal zone, and then added the ports I knock on to the Ports section of the GUI. I also selected the TCP protocol because that is what my knock client is using to send the knocks to these ports. This did not work.
What is "internal zone"? Is it the literal name of firewalld zone? Is it colloquial name for some zone you use for internal interfaces? Do you have more than one zone? What zone is assigned to interface used to access you knockd?
The internal zone is a pre-configured zone that the firewall GUI (firewall-config) already knows about after it is installed. I assigned my NIC (eth0) that is connected to my internal private network, (192.168.10.0/24) to the internal zone.
It is rather strange to use "internal" zone for an interface obviously facing external hosts (Internet). While the name does not really matter, common assumption is that "internal" refers to your internal trusted network. It just makes it harder for anyone to understand your intended configuration.
If the knockd.service daemon had heard the knocks then it would have used the following command configuration to open that actual port for the service I am trying to access. For example, for SSH, I send the port knock sequence to the ports xxxx,yyyy,zzzz (obscured) and it is these
Well, as you preferred to hide ports that you really need to open, the whole copious output of current netfilter configuration becomes entirely useless as we do not even know what to check it for. ...
I then set up tcpdump to monitor all interfaces for incoming knocks and I got a surprise, tcpdump showed me that the knocks were being heard on eth1, not eth0 like I expected! eth0 is assigned the address of
This is the first time you mentioned that you have multiple interfaces. If you did it from the very beginning, the very first obvious question would have been verifying that communication goes via the correct interface.
192.168.10.20 and used for my internal firewall zone, eth1 is assigned the address of 192.168.10.21, assigned to my external firewall zone, and
That is not going to work. You cannot have two interfaces in the same broadcast domain and network in two different firewall zones without hitting all sort of weird corner cases like your current problem.
is for something I plan for in the future but not using it at the moment. Nevertheless, when I monitor eth1 with tcpdump, send the knocks, I get this -
tcpdump -i eth1 'src 192.168.10.10 and portrange xxxx-zzzz and tcp' -nn tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:54:22.992496 IP 192.168.10.10.51646 > 192.168.10.20.xxxx: Flags [S], seq 767482099, win 64240, options [mss 1460,sackOK,TS val 3057886337 ecr 0,nop,wscale 7], length 0 10:54:24.008921 IP 192.168.10.10.50170 > 192.168.10.20.yyyy: Flags [S], seq 3733321455, win 64240, options [mss 1460,sackOK,TS val 3057887354 ecr 0,nop,wscale 7], length 0 10:54:25.023226 IP 192.168.10.10.42834 > 192.168.10.20.zzzz: Flags [S], seq 2867229806, win 64240, options [mss 1460,sackOK,TS val 3057888368 ecr 0,nop,wscale 7], length 0 ^C 3 packets captured 3 packets received by filter 0 packets dropped by kernel
So the knocks did show up, but on the wrong interface. Both tcpdump and my own double checking of the knocks being sent from my laptop, show that the knocks are being sent to 192.168.10.20. Why they are showing up on 192.168.10.21 is beyond my ability to grok,
By default Linux will answer ARP request for any local host address on any interface so it works as designed. You can change it by setting net.ipv4.conf.*.arp_ignore sysctl to 1 (or 2 or 3 depending on your requirements). https://serverfault.com/questions/834512/why-does-linux-answer-to-arp-on-inc...
but both of these interfaces are handled by a dual NIC card, so I am now thinking there is something wrong with this card. It is a dual port RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller card. If anyone wants to know the particulars about the card, I can send a link to Amazon for the one I purchased.
...
buying another NIC will be the permanent solution.
It has nothing to do with your card, but hey, it is your money you are going to throw out.