I have never been able to sort this out. I have NAS on the same subnet but am accessing through a laptop, also on the subnet but I cannot, nor have I ever been able to enable minimwatch on the laptop to talk to mimimserver on the NAS wit the firewall running. The only way I can get functioning minimwatch is if I turn off the firewall.
Minimwatch directions say allow UDP traffic on port 1900 and I have done this in every conceivable way in the firewall window but no luck. Only turning off firewall works.
How can I sort this out please?
Budge.
No luck so far. I have enabled 1900/UDP, 9790/TCP, 9791/TCP on all interfaces and added upnp-client on all too.
I am having to try hit and miss here. Surely there is a means to sniff out which packets are being dropped so that the FW can be edited to allow the required traffic.
Will keep trying.
Budge
I have it now and have been trying to sort out what I have found. I have a candidate trying to connect to this machine (on which I am typing at present) from the relevant server:-
So many questions but which port is the right one here? Also if these ports are set dynamically how can they be filtered? More reading by me is required I think but meanwhile what should I try next please?
I do not know what “right” is supposed to mean. Destination port is obviously 57221.
Also if these ports are set dynamically how can they be filtered?
If your application is really expecting incoming connection on some random port and it announces this port to the partner over other connection, you would need to write connection tracking helper (either in kernel on in user space) that parses this other connection and opens required port. Or configure your application to use fixed port.
You really need to ask on your application support channels what are firewall requirements. We have no way to guess them.
Hi and thanks for the reply. I did of course start with the application writer a while ago. As far as he is concerned the port should be set:-
If MinimServer is running but MinimWatch 2 can’t see MinimServer, check that you don’t have a firewall blocking port udp/1900.
Minimserver is running on a NAS and I am still trying to work out where the problem is. In my ignorance I have captured a short extract from the firewall log, from which I conclude that minimserver is trying to talk to minimwatch on my laptop but traffic on Port 9791 is not getting through.
On the other hand looking at the firewall log it seems some form of dynamic port configuration is being used and I cannot find where or how this is set. I have now asked the NAS supplier and am trying to learn more.
I am sorry I was less than precise by referring to “correct” port. I am still trying to work out which of the several packet ports which feature in my data grab might be relevant or used in my firewall.
I have checked the minimwatch log and here is an extract from the log:-
MinimServer[QnapNas2] is running
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 1)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 2)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 3)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 4)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 5)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 6)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 7)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 8)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 9)
Retrying monitor subscription for server at 192.168.169.130:9791 (attempt 10)
Clearly port 9791 is being used, I think this is telling me that minimserver on 192.168.169.130 is sending on port 9791. Is this right or is it the reverse?
However grabbing a section from the firewall log I have what is given below:-
Sorry I have snipped so much but you can see why I thought some dynamic process was in use because of the ports being used.
Am I correct in my interpretation of the data?
I should add that minimwatch using windoze on this laptop does work so I assume there is not a problem at the server end.
Can you shine any more light on this for me please?
Hi Budgie. As arvidjaar already indicated, this communication protocol requires connection tracking from a firewall perspective. A simple approach would be just to permit UDP traffic (any port) from the server IP address. This is not secure for obvious reasons, but if you are in a private network with trusted hosts and an internet facing firewall, it might be acceptable
Alternatively, I did find this thread discussing how UPnP SSDP works (and why it is problematic with Linux firewalls)…
A user describes using ipset as a connection tracking workaround with the following approach…
ipset create upnp hash:ip,port timeout 3
iptables -A OUTPUT -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j SET --add-set upnp src,src --exist
iptables -A INPUT -p udp -m set --match-set upnp dst,dst -j ACCEPT
As explained in the thread, the commands work as follows…
First command creates a new ipset called upnp which stores tuple (ip address, ip protocol, ip port) and every inserted record expires in 3 seconds.
Second command matches outgoing UPnP SSDP packet (destination is multicast address 239.255.255.250 on udp port 1900) and stores source ip address and source udp port of packet into ipset upnp. First keyword src means source ip address and second keyword src means source port as ipset of type hash:ip,port always needs such pair. Keyword –exists means that for existing record is timer reseted. This stored record is automatically removed in 3 seconds.
Third command matches incoming udp packet and if its destination address and destination port matches some record in ipset upnp then this packet is accepted. Syntax dst,dst means destination ip address and destination port.
UPnP clients normally sends udp packet to 239.255.255.250:1090 and wait just 2 seconds for response. So autoexpiration in 3 seconds in ipset is enough.
Hi Deano,
Very many thanks for your reply. Now I am beginning to understand the underlying problem, which confirms my dislike for UPnP but I guess I am stuck with it!
Before I try your scripts I shall need to read a bit more from the earlier threads and the clear and helpful tutorial.
I did spend some time on firewalld back when openSUSE 15.? first introduced it. At that time the documentation was poor and I had a real struggle. Later the Yast system simplified use of the firewall but now I think I had better sort out my interfaces and be clear in my mind what I am trying to do. It has recently become more critical as I shall be working in a more public and commercial environment.
Give me a few days as I have some other infrastructure work to do but will get back on this later in the week.
Hope all is OK with you after the earthquake. Some of my family live on the south west coast so no problems for them but another family member who lives in threatened area called and told us what was happening as she ran up hill as instructed!!! (She is a hill runner so was able to talk at the same time.)
Not mine…the firewall-cmd commands are for direct rules based on the thread I linked to.
I did spend some time on firewalld back when openSUSE 15.? first introduced it. At that time the documentation was poor and I had a real struggle. Later the Yast system simplified use of the firewall but now I think I had better sort out my interfaces and be clear in my mind what I am trying to do. It has recently become more critical as I shall be working in a more public and commercial environment.
Give me a few days as I have some other infrastructure work to do but will get back on this later in the week.
All good. Hopefully, the approach described in my last post will do the trick for allowing what the firewall considers “unsolicited/unrelated” UDP traffic.
Hope all is OK with you after the earthquake. Some of my family live on the south west coast so no problems for them but another family member who lives in threatened area called and told us what was happening as she ran up hill as instructed!!! (She is a hill runner so was able to talk at the same time.)
Regards,
Budge.
Yes, all ok thanks. I slept through the first jolt, and didn’t feel the others from my work location in Auckland. We live in a low-lying area, but no evacuation warning for that particular location fortunately.
What about the direct interface? Seasoned firewalld users may already be asking themselves, What about the direct interface? No worries, it’s still there and works almost exactly as it did in previous releases. When the nftables backend is enabled direct rules are treated specially and still use iptables and family. This means your existing configurations with custom direct rules will continue to work. However, there is one deliberate behavioral change - direct rules take precedence over all other firewalld rules. For further details see the Behavorial Changes section below.
Hi Deano,
I tried your commands for firewalld direct rules. Each command gave me “success” after running. I used the ip address for the remote NAS which is on static IP running the mediaserver and set the Backend to iptables instead of nftables.
I may not have followed it all correctly but have tried. Unfortunately my minimwatch icon is still grey not green.
I have set UDP on 1900 as in the minimserver instructions and 9790 and 9791 (not instructed but gathered from other reading,) on all zones as I am still trying to work out what zones I should use. Will post separately on my choice for zones.
If you’re referring to the multicast address (239.255.255.250/32 ), that should be left as is.
I have set UDP on 1900 as in the minimserver instructions and 9790 and 9791 (not instructed but gathered from other reading,) on all zones as I am still trying to work out what zones I should use. Will post separately on my choice for zones.
Not sure what to try next
Budge
Please show us
firewall-cmd --list-all
as already requested at the beginning of this thread.
