nftables - One machine not able to access server

Question

I am working on setting up my firewall on my server right now and it drives me crazy. I am using nftables aand have the following ruleset:

table inet filter {
    map whitelist {
            type ipv4_addr . inet_service : verdict
            elements = { 192.168.1.x . ssh : accept,
                         192.168.1.y . ssh : accept,
                         192.168.1.z . ssh : accept }
    }

    chain input {
            type filter hook input priority 0; policy accept;
            ct state established,related accept
            iifname "lo" accept
            tcp dport http ip saddr { 192.168.1.0/24 } accept comment "Accept HTTP traffic on PORT 80"
            tcp dport netbios-ns ip saddr { 192.168.1.0/24 } accept comment "Accept NetBIOS Name Service (nmbd) on PORT 137"
            tcp dport netbios-dgm ip saddr { 192.168.1.0/24 } accept comment "Accept NetBIOS Datagram Service (nmbd) on PORT 138"
            tcp dport netbios-ssn ip saddr { 192.168.1.0/24 } accept comment "Accept NetBIOS Session Service (smbd) on PORT 139"
            tcp dport https ip saddr { 192.168.1.0/24 } accept comment "Accept HTTPS traffic on PORT 443"
            tcp dport microsoft-ds ip saddr { 192.168.1.0/24 } accept comment "Accept Microsoft Directory Services (smbd) on PORT 445"
            tcp dport webmin ip saddr { 192.168.1.0/24 } accept comment "Accept traffic for WebMin Interface on PORT 10000"
            udp dport netbios-ns ip saddr { 192.168.1.0/24 } accept comment "Accept NetBIOS Name Service (nmdb) on PORT 137"
            udp dport netbios-dgm ip saddr { 192.168.1.0/24 } accept comment "Accept NetBIOS Datagram Service (nmbd) on PORT 138"
            udp dport netbios-ssn ip saddr { 192.168.1.0/24 } accept comment "Accept NetBIOS Session Service (nmdb) on PORT 139"
            udp dport microsoft-ds ip saddr { 192.168.1.0/24 } accept comment "Accept Microsoft Directory Service (smbd) on PORT 445"
            meta nfproto ipv4 ip saddr . tcp dport vmap @whitelist
            drop
    }

    chain output {
            type filter hook output priority 0; policy accept;
    }

    chain forward {
            type filter hook forward priority 0; policy drop;
    }

}

I made sure the network range defined above is within the correct range. The range covers 254 addresses and my machines should be fine. I have no issues with my main machine as well one other one. These two machines have the IPs 192.168.1.42 and 192.168.1.181. But one other machine drives me crazy. As soon as the drop part is added that machine with the IP 192.168.1.115 cannot access the server anymore. My question is, as I just can't figure out why this one machine does not want to access the data on the server anymore, is there anything obvious why this access would not work? What am I missing?

thanks

realshadow

Are you sure it is a problem of firewall ? If you remove it the faulty machine works with your server ? Can it be a error in netmask, a ARP error ? — Dom, May 27 '20 at 18:04
@Dom At least netmask it is not the issue. I checked it is 255.255.255.0 for all of my machines in the network. As soon as I remove the ```drop``` everything works fine. I am really struggling understanding that issue especially where the IP ranges are set correctly. — realShadow, May 27 '20 at 20:06
So i should be the Firewall. Could you add a log at the end of drop line? Then you will see the packets details and you can analyze it. — Dom, May 28 '20 at 06:09
@Dom I will do that and report back once I have the data. Might take me some time though. At work now. — realShadow, May 28 '20 at 14:05
@Dom So I did what you said. It is really weird because the packets seem not to be counted once the drop option is removed. With the drop option included the packets are counted and I can see some traffic hitting the firewall. I am so not getting any smarter out of these results. I checked the netmask (AGAIN) in both the firewall and the computer itself. This is not making any sense... `ip saddr 192.168.1.115 counter packets 36 bytes 2448 # handle 34` — realShadow, May 28 '20 at 17:48
My last idea is : try to add the rule SSH ACCEPT only from 192.168.1.115 before drop. It may be the meta which doesn't works — Dom, May 28 '20 at 17:58
@Dom thanks for your help. I really appreciate that. Unfortunately even though I added the machine to the whitelist it did not resolve my issue. I cannot access the server through SMB or NetBIOS functionality from that one machine with the drop handle in the firewall which was so crucial in my security setup. Again. Really appreciate your help and providing me with ideas. — realShadow, May 28 '20 at 20:31
@Dom I figured it out. You pushed me in the right direction. The issue was that the computer could not resolve the name properly. I had to add the server's IP and name to the hosts file in windows. Once that was done I could reach the server. I was convinced my router did take care of DNS in my network. Well, obviously I was wrong.THANKS FOR YOUR HELP. I would not have found it without it!!! — realShadow, May 28 '20 at 20:48

nftables - One machine not able to access server

0 Answers0