is open because of the CLoudFlare handling of the proxy, but from CloudFlare to my server, nothing works. I'm starting to think that my ISP blocks 80 and 443 inbound, and therefore does not reach my server. When I check online for open ports using my public IP both 80 and 443 are unreachable. So, in theory I should be bale to get to ''. CNAME is 'meet' that points to the root domain 'mydomain.ca'. I used the DNS validation for Let's Encrypt, also allowing me to do a wildcard cert. I have my own domain - which I point to my public IP since it never changes (Hasn't in three years). if any of that makes any sense as i am far from an expert on any of this. it separates them from other containers and directs the traffic via lets encrypt.ĭomain CNAME for jitsi (Points to) -> single duckdns domain (Maintains my public ip) -> Firewall has dynamic DNS setup for duck DNS (updates my public IP to duck DNS) -> ports forwarded in my firewall as per Lents encrypt video (443 to 1443 & 80 to 180) -> lets encrypt container includes my jitsi domain & letsencrypt config (proxy conf) setup with my domain rather than the default. My real unRaid server IP has access as it needs. Therefor I am to believe that I need nothing for this on my actual LAN to configure, nor any policies to allow it. However, I got the impression from the videos that the proxynet is an internal virtual network created within unRaid which it will use to handle proxied traffic. So here is a question:ĭo i need to configure the proxynet in my local network to ensure that I can allow this network access to the outside? I run an enterprise FortiGate firewall at home, so nothing is permitted unless I tell it to. When it came to adding the Jitsi stack, I followed along and configured all 4 instances to use the proxynet, and removed the self-created networks. and in setting up the networks I used SpaceInvader's letsencrypt video.

Jitsi meet no volume