Port forward 8123, TCP and UDP?

Hi,
My router when setting up port forwarding 443 to 8123, asked if it was to handle just TCP or both TCP and UDP. I set it for both, presume the server needs UDP also ??

Thanks

And unless you have setup proper reverse proxy with SSL dont do that unless you like to be owned?

Also I don’t think the front end uses UDP it’s all http or https traffic

1 Like

Thanks for your comment …

I was following this Youtube:
‘Home Assistant Remote Access using DuckDNS and LetsEncrypt’:

… it suggests the configuration 443 > 8123 (looks like we have the same router interface).

I thought https would be coming in on 443, or is the above wrong, and it can simply be 8123 > 8123.
I note your comment, TCP only.

Looks like I need to learn how to setup reverse proxy with SSL, I see NGINX mentioned, will this do what I need ?

I see this guide:

Better don’t do it as you can easily give access to the whole net to your home.

Start with nabu casa cloud and learn something about it if you are so passionate to use your own solution for remote access.

1 Like

Eh. :man_shrugging: DuckDNS includes LetsEncrypt SSL certs. The ports do get scanned and intrusion attempts do occur but HA is good at rejecting them.

Using MFA and IPBan I had no concerns when I was using DuckDNS.

This is just FUD.

Set up properly DuckDNS is fine.

And yes, both UDP and TCP.

You only Need the reverse proxy if you want local http access.

2 Likes

It is not. I did set up remote access using cloudflare tunnel a few years ago and shut it down after 24 hours. Doesn’t need any port forwarding on router.

OP in my opinion is just someone who is getting familiar with those things and I wouldn’t recommend to no one to set up it’s own remote access unless he really know what is he doing.

This has nothing to do with your attempts to use Cloudflare.

Thousands of people happily use DuckDNS + LetsEncrypt quite safely. Sure you get the occasional warning message that someone was knocking at the door but HA did not let them in.

The tutorial they are following is fine and they seem to have a grasp on what is required. So again, please stop with the FUD.

2 Likes

You only need TCP for HA (and indeed for most web services - only with the arrival of QUIC and HTTP/3 has UDP been supported).

I was more worried about someone redirecting 443 in the clear. That was more important than clarification of how first. There wasn’t any info on how. Was going to ask the plan later.

  1. make sure the patient doesn’t die. Admin cpr
  2. THEN fix the broken rib from cpr
1 Like

FUD LOL, not heard that phrase before, but yes - it can dent ones confidence, its got me questioning some things now.

I need to do some more studying.
Do I need to get my head around reverse proxies, which sure I can do …

I have read this:

It suggests 443 > 8123 and using NGINX and to make some changes to the configuration.yaml

… I think this chaps setup is all about being able to put the proxy up front to deal with secure traffic, whilst also letting unsecure traffic within the LAN connect unencrypted to HAOS, if at all possible I am interested in it all being secure though (ie from inside and outside),

Is forwarding 443 > 8123, secure from the router to HAOS server (ie within my NW), without a reverse proxy.

I need to understand more about forwarding, ie, why do we port forward 443 > 8123, why not forward 8123 > 8123, is that not all going inside a secure https connection, or does https/443 invoke the SSL certificate requirement, in combination with domain DNS enquiries (which I have yet to look into), hence traffic from within the LAN using IP’s are currently insecure.

Which one, TCP only or TCP and UDP, I have two different answers above.

Can one assume, that out of the boxHOAS is a reasonably locked down version of Linux (Debian ?).

Only connections I am wanting to make at this point is with a Browser, and the Android App. All my devices are Zigbee, so no WiFi requirement.

I have two factor authentication setup,

I have Nmap scanned my network from outside, and apart from 3 other ports related to other devices, (I think all at the router), only 443 is detected.
I would still like to work out how to probe 443 a bit closer with nmap, or other pen testing tools.

The server has been running for a couple of weeks now, all seems fine, only had one uninvited visitor from China who knocked on the door once, I presume the logs will keep a note of all these attempts.

I didn’t wrote that to dent you confidence. If you are confident to do it, well do it.
But if your are not then common sense will be not to do it.
As others people opinion goes, well everyone have opinion.

I’ll add my 2 cents…
Regarding port 443, there is one scenario I’ll share and is probably a very narrow application, but… There is a way to setup Alexa whereby you can see your HA cameras on an Alexa device that has a display, but it requires that HA be accessible from the external world via 443.

Forwarding a port itself is neither secure nor insecure, it’s what you forward it to and how that is configured that determines that.

Forward it to a service running TLS/SSL*, with MFA, that’s (probably) secure. No SSL and use admin/password as your login, that’s horribly insecure. If the underlying app has a long list of exploitable vulnerabilities (HA doesn’t, as far as I’m aware) then neither option there is “secure” because the app isn’t.

It makes no difference at all, ports are just numbers, like door numbers, they don’t bring security (or a lack of).

No

You can (for this anyway) use any port you want, they’re just numbers. Now, using a default or common port does make it more likely that port scanners will find you. Like having a front door makes it easier for door-to-door sales people to find your door. Having the door around the side doesn’t stop most of them from finding it though, just like not using a default/common port won’t find most scanners from finding you. Moving the door/changing the port doesn’t have any impact on security - at most it may change the amount of noise in your log.

Look up what protocol HTTP uses and you’ll see it uses TCP - until the arrival of QUIC and HTTP/3 anyway. For the purposes of HA it doesn’t (yet?) support QUIC or HTTP/3, so TCP is all you need.

It’s a minimal BuildRoot based OS, so yes.

Then you’ve got less to worry about, at least as long as you use SSL.

  • SSL has been dead for years, replaced by TLS. However most people still refer to TLS as SSL, and the certificates are typically called SSL certificate so for the purposes of simplicity I’ll just talk about SSL.
2 Likes

Thanks for all that info, very helpful.

I’ve seen some more nefarious attempts to login - from china, but they’ve all been waved away by HAOS.

I need to find out more about how duckdns addon and letsencrypt certificates work together, along with the whole authentication/challenge and validation process.

The important part of the secure certificate, the Private Key, I dont remember being given an option to back up the key separately - unless i missed something, is this held on the HAOS server somewhere and gets backed up with the general backup function ? Excuse the lame question.

Mostly they don’t.

  • DuckDNS: Resolves yourhost.example.com to your current WAN IP. It does nothing else.
  • LetsEncrypt: Provides an SSL certificate for yourhost.example.com after you prove you have control of that domain

Yes, have you read the DuckDNS add-on’s docs? You can find those files in /ssl/.

Those are separate from SSL etc and can be found here.

1 Like