Ok so i recently have setup UFW on 3 hosts that are on 24/7 and are being backed up 3 times a day(both clients and the server are in the same LAN), i ofcourse was curious to find what kind of traffic was blocked so i checked and i noticed some strange traffic:
What i see is the source is the backup server (which i gave a very “nice” ip as you can see). And appears to be sending packets from the port on which it has the webinterface running to some arbitrary port on the client and is blocked. Urbackupsrv sees them to be online and the backups run fine. I see this with all of the three clients. The port was not listed as an incoming port for the clients at UrBackup - Server administration manual. Also the webgui (http) is not accessed from those clients, so its not like there is some unfinished web(page) traffic. In fact i proxy’d 55414->55416 to expose the webgui via ssl. The original port, 55415 isnt even accessible. So what is going on here?
Btw, for those interessted, easy peasy copy paste the following in a file /etc/ufw/applications.d:
[urbackup-client]
title=Connections to urbackupclientbackend
description=Use this to allow incoming connections from a specific urbackup server to the urbackup client backend
ports=35622/udp|35623/tcp|35621/tcp
And suppose your backup server has ip 192.168.10.96, on the client the command to setup UFW is (assuming incoming policy either drop or reject):
ufw allow from 192.168.10.96 to $(hostname -I) app urbackup-client
You could also change the target IP (which is determined by that hostname -I command, check the output in advance) to “any”, but im a paranoid bastard. Keep an eye on this thread, the application profile might need an update if what i described above is indeed wrongfully blocked traffic. Technically speaking broadcasts should go to “any”, but in my scenario this seems to work perfectly.