Are you wanting to access your sites remotely or only via the local LAN?
If you’re aiming for remote access then you can’t use the 192.168.* range as that’s the up address behind your NAT/router. You have use your public IP and do port forwarding from your router.
If you’re worried about your IoT devices on your LAN the problem isn’t necessarily that they can access WAN but rather that there’s a security vulnerability and that they can be accessed by the WAN. Once a device is compromised and attacker can then use it as a “beachhead” to access other devices on your network.
So for example, with my setup every IoT device is on a separate VLAN (the guest network acts similarly) which can’t get access to WAN, can’t be accessed from the WAN and can’t initiate any network calls to any other VLAN. Now my primary VLAN can talk to my IoT VLAN, and IoT can talk back, it just can’t start the communication.
This does pose a problem for TVs though that need to talk to Jellyfin as hinted at in the original post. So what you could do is create a specific firewall rule that allows the TVs to at least initiate communication to Jellyfin but not any other device on your primary VLAN. This will probably require a more sophisticated router though than most of the consumer ones out there. Just be mindful that if n IoT device is compromised they can then try to attack the jellyfin server to jump to your other VLAN and then the rest of your network.
Just wanted to add… After reading your initial post I did some more digging on adding tracking headers, etc… especially by T-Mobile.
While it’s definitely a thing, it only applies to HTTP traffic. Even HTTPS blocks their ability to add those headers. So any traffic that’s using any other protocol (DNS, email, ssh, or just gaming, etc…) would be safe from your ISP from at least trying to add these tracking headers.
Yes but while the service is targeted for home use there still is remote work which generally requires a VPN back to the company network. They wouldn’t be able to block this. Now sure they might be more inclined to block Mullvad but they’d impact too many businesses by blocking wireguard as a whole.
And assuming they did block Mullvad but not wireguard… Just rent a VPS and install a wireguard server and client there to bridge back to Mullvad.
I know this doesn’t help much but I use T-Mobile cell towers with an always on VPN with no issue. But I don’t see why they’d block Mullvad. (I’d be more concerned that they’d block them than wireguard in general). But there’s completely legitimate reasons to use both so I don’t see them really bothering to block either.
If it was a certificate issue I’d expect youd just get an error from your browser saying the cert is invalid or expired.
If I had to guess though you’re running into a nat reflection issue: https://nordvpn.com/cybersecurity/glossary/nat-loopback/
Read up on that. But you may need to provide different DNS entries if you’re inside or outside your LAN or add a NAT hairpin rule to your router. But this is only applicable if you’re exposing the same service to the WWW.
Some other things to try though:
I’ve tried commenting out the ports in the compose file, which should make them only available on the internal network, I thought. But when I do that, the containers can no longer connect to each other.
Did you create an explicit network for them to talk on? Otherwise the default docker network doesn’t support internal DNS queries.
https://docs.docker.com/engine/network/#container-networks
Specifically you need a network using the bridge driver: https://docs.docker.com/engine/network/drivers/bridge/
Are you able to query to see what IP address that domain returns? Does it return the 192.168.x address that you set?
Edit: But the idea is to first see where the connection is failing… first see what error your browser is returning? 5xx? 4xx? This can be an indication as to where the error is happening. But high-level check DNS first, see if
nslookupordigreturn the IP address that you set. (Remember changes to DNS entries can take time to propagate). Assuming all of that is correct, then check to see what nginx is showing in its logs. Do you see it logging anything every time you try and access it via the domain name? Next up is checking the logs from plex itself, does it show any logs coming though? etc… But the idea is to find where the connection is breaking down.