Selfhosted

I would recommend not exposing a bunch of services to the internet. Ideally you would expose only a VPN and connect to everything that way.

I would advise to not do personal stuff on your work computer.

Just use port 443 or 80 and use sub domains and a reverse proxy for each of your services.

For example:

https://rss.example.com/ goes to port 443 on your server where you run a nginx with letsencrypt. You set up a vhost for this subdomain which then internally proxies to your IP adress and port for freshrss.

I have it like that: https://rss.jeena.net/ and https://piefed.jeena.net/ and https://toot.jeena.net/ and so on.

Enterprise firewalls can detect if you’re running services on non-standard ports.

For example if you try to use ssh on port 443, I block that.

If you try to use https on 8443 I block that.

Also if your domain is on a dynamic dns domain or is relatively new then it might get blocked.

Use a reverse proxy like Traefik to access your seevices via subdomain like paperless.uourdomain.com.

The advantage of that approach is you will be connected to Traefik on port either 443 or 80 (based on your Traefik setup). Most firewall will allow connection to port 443 or 80.

I can think of a couple of reasons off the top of my head.

You don't say, but I assume you are working on-site with your work system. So, the first consideration would be a firewall at your work's network perimeter. A common security practice is to block outbound connections on unusual ports. This usually means anything not 80/tcp or 443/tcp. Other ports will be allowed on an exception basis. For example, developers may be allowed to access 22/tcp outbound, though that may also be limited to only specific remote IP addresses.

You may also have some sort of proxy and/or Cloud Access Security Broker (CASB) software running on your work system. This setup would be used to inspect the network connections your work system is making and allow/block based on various policy settings. For example, a CASB might be configured to look at a domain reputation service and block connections to any domain whose reputation is consider suspect or malicious. Domains may also be blocked based on things like age, or category. For this type of block, the port used won't matter. It will just be "domain something.tld looks sketchy, so block all the things". With "sketchy" being defined by the company in it's various access policies.

A last reason could be application control. If the services you are trying to connect to rely on a local program running on your work system, it's possible that the system is set to prevent unknown applications from running. This setup is less common, but it growing in popularity (it just sucks big old donkey balls to get setup and maintain). The idea being that only known and trusted applications are allowed to run on the system, and everything else is blocked by default. This looks like an application just crashing to the end user (you), but it provides a pretty nice layer of protection for the network defenders.

Messing with the local pc is of course forbidden.

Ya, that's pretty normal. If you have something you really need to use, talk with your network security team. Most of us network defenders are pretty reasonable people who just want to keep the network safe, without impacting the business. That said, I suspect you're going to run into issues with what you are trying to run. Something like SyncThing or some cloud based storage is really useful for businesses. But, businesses aren't going to be so keen to have you backing their data up to your home server. Sure, that might not be your intention, but this is now another possible path for data to leave the network which they need to keep an eye on. All because you want to store your personal data on your work system. That's not going to go over well. Even worse, you're probably going to be somewhat resistant when they ask you to start feeding your server's logs into the businesses log repository. Since this is what they would need to prove that you aren't sending business data to it. It's just a bad idea all around.

I'd suspect Paperless is going to run into similar issues. It's a pretty obvious way for you to steal company data. Sure, this is probably not your intention, but the network defenders have to consider that possibility. Again, they are likely to outright deny it. Though if you and enough folks at your company want to use something like this, talk with your IT teams, it might be possible to get an instance hosted by the business for business use. There is no guarantee, but if it's a useful productivity package, maybe you will have a really positive project under your belt to talk about.

FreshRSS you might be able to get going. Instead of segregating services by port, stand up something like NGinx on port 443 and configure it as a reverse proxy. Use host headers to separate services such that you have sync.yourdomain.tld mapped to your SyncThing instance, office.yourdomain.tld mapped to your paperless instance and rss.yourdomain.tld mapped to FreshRSS. This gets you around issues with port blocking and makes managing TLS certificates easier. You can have a single cert sitting in front of all your services, rather than needing to configure TLS for each service individually.

Ssh port forwarding and socks proxying. Unless they block port 22.

Edit: If they do block port 22 run ssh on port 443.