I am in the middle of migrating from Core to Scale because I expected to be able to use more apps but no luck.
I bought “new” drives, installed Dragonfish-24.04.1.1, fixed new empty pool and replicated all data from my other server.
Everything was fine until I tried to install few apps like Plex, qBittorrent, Emby, Jellyfin etc…
None of the apps have normal IP from my DHCP pool like it was in Core but using preset IP’s like 172.x.x.x Because of this Plex, Emby and Jellyfin are not visible on the internet. Plex is unable to register in my account since it’s not seen from outside.
Please, can somebody suggest me a solution how to fix these network issues with the apps and set normal IP’s ? Also I prefer some apps like Nextcloud to have public IP address to be able to access it from everywhere.
Reverse proxy to where ?
Never had need of using proxy of any kind.
I have plenty of IPv6 addresses and can get as much as I need IPv4.
I am using pfSense as router/firewall and fixed separate vlan just for the truenas apps to use it and eventually get IP addresses from.
The default route in any app/custom app Ive tried is pinned to the 172. interface, and not the external interfaces added to the app through the web gui. It is forced to NAT from that to the NAS interface.
This works differently to Container Station on a QNAP or Portainer.
It is a real pain. All the traffic from the apps is coming from the same ip address as the NAS itself, and because of that, my policy based routing broke.
If we could have a way to specify the default route and interface for each app it would likely fix all your issues.
You are missing something then. If you have a bridge interface, then in the custom app, you can set your ip to anything you want, static, and, set the default route to your router, whatever. I have a number of static ips via custom apps. Even DLNA works then, as otherwise it’s pinned to the private network.
To be clear - not speaking of exposing anything on 172. network. Here is an example from my custom app for caddy:
Seems the best way could be making a bridge between apps subnet 172.x.x.x/16 and expose entire subnet as separate interface in my pfSense router. Seems to do this I have to choose a random IP from this subnet to put it on that interface and then I would be able to route everything to wherever I want.
What if I try to install pfSense as custom app or virtual machine ? LOL
Strange I have a similar config, yet ip route show in the pod shows 172 interface as the default. Is your 192.168.3.x subnet the same as the TrueNAS management interface? The external interface and TrueNAS interface are the same subnet on mine, I’m wondering if maybe that has something to do with it?
Yours is fine. Default network for you is 172.16.0.1 but anything destined for 192.168.178.0/24 routes directly via 192.168.178.32. What’s wrong with that? You’ll always have both networks, as one can reference other containers from within a container and that will use the default route in that case and not NAT it. A perfect example of that is again my caddy. Caddy (reverse proxy) talks to the other containers via the kubernetes private lan as it’s less efficient to route otherwise. Those other containers are references via their kubernetes dns names.
I cannot see the real source of the traffic on my firewall destined for www - it’s all coming from the NAS interface.
Which means that my policy based routing on the firewall doesn’t work, eg I have rules if source is 192.168.178.32 use WAN Gateway 2 (my firewall has two WAN connections).
Each app has its own interface and IP, that part works fine, I just desperately wish 0.0.0.0/0 was on net1 not eth0.
I’m hoping this magically fixes this thing, I haven’t the knowledge or time to look into this default route deal with Kubernetes, for now I’ve just added the management IP of the NAS to my policy based routing and it does what I need.
Strange, my traffic comes from the static ip in all tools, even dlna. You must have another setting somewhere off. I guess go with your simple solution for now, save time, and re-visit when Eel comes out. Docker does create it’s own network also, though, it remains to be seen how it is implemented in Eel. I’m going to be running the Eel Beta once the code is checked in for Docker stuff and hope to test out as many uses as possible. For me, for example, it’s annoying that I have to manually set a static IP today, the mac address changes every time you run the container so hoping for a better experience.
