Problem/Justification
The current networking configuration in TrueNAS Scale does not allow assigning multiple interfaces with unique static IPs within the same subnet. This is a standard and valid practice in networking, used globally for redundancy, load balancing, or separating services across different IPs. The restriction forces users to rely on workarounds like VLANs, NAT, or port-forwarding, which are unnecessarily complex for straightforward use cases.
For example:
Users cannot configure one interface with 10.0.0.19 for a DNS server (e.g., Pi-hole) and another interface with 10.0.0.20 for other services within the same /20 subnet.
Services like DNS require direct IP access (10.0.0.19) and cannot work effectively with port-forwarding (e.g., 10.0.0.19:8080).
This restriction limits TrueNAS Scale’s usability in advanced and enterprise networking scenarios, creating unnecessary complexity for users with diverse service needs.
Impact Benefits and Advantages:
Increased Flexibility: Supporting multiple interfaces with static IPs on the same subnet enables users to separate services more efficiently, reducing port conflicts and the need for complex configurations.
Improved Usability: Eliminates reliance on VLANs or NAT for straightforward setups, aligning TrueNAS Scale with standard networking practices.
Enhanced Enterprise Appeal: Advanced users and enterprises can leverage this feature to better manage redundancy, load balancing, and service separation.
Disadvantages:
This change would require updates to the networking stack and may introduce complexity in handling edge cases or misconfigurations.
Documentation and support would need to address potential pitfalls (e.g., routing conflicts or incorrect setups).
User Story As a user, I want to configure multiple RJ45 ports on my TrueNAS Scale server with unique static IPs within the same subnet so that I can assign each IP to a specific service or container.
Steps:
Navigate to the networking configuration in TrueNAS.
Assign 10.0.0.19 to Interface 1 and 10.0.0.20 to Interface 2, both within the /20 subnet.
Assign 10.0.0.19 to Pi-hole for DNS and 10.0.0.20 to another containerized service, such as a web server.
Access Pi-hole directly via 10.0.0.19 and the web server via 10.0.0.20, without the need for port-forwarding.
This workflow simplifies service separation, reduces conflicts, and aligns with standard networking practices.
First, let me clarify that you’ve taken my sentence out of context. I never implied that multiple interfaces on the same subnet is a universal practice for every network setup. My statement was that it’s a valid and standard practice when configured correctly in specific scenarios, such as service separation, redundancy, or traffic isolation—particularly in internal networks or lab environments.
For context, I’ve also managed networks for one of the largest data center companies in Europe, working with setups involving Google, Microsoft, and Amazon Cloud. Additionally, I was part of the Lavabit team (Edward Snowden’s email provider) and specialize in cybersecurity and secure software development. So, I’m not debating this from a lack of experience or understanding.
The core of the issue is not whether this configuration aligns with your personal experience. The issue is that TrueNAS has deliberately blocked this configuration with one line of code, making it impossible for advanced users to implement a setup that works perfectly fine on other platforms like Synology, Unraid, and OpenMediaVault.
I’ve explained the problem in detail, and there is no current solution within TrueNAS for scenarios where:
Two services (e.g., Pi-hole and Jellyfin) need separate IPs on the same subnet.
Both services need to run on port 80 without requiring VLANs or NAT.
This restriction is arbitrary and unnecessarily limits the flexibility of TrueNAS. If you have a practical solution to the specific problem I’ve raised, I’d genuinely love to hear it. Otherwise, the focus should remain on addressing the limitations of TrueNAS’ current implementation.
I appreciate your feedback, but your comment lacks any technical explanation or constructive input. Dismissing the request by claiming I don’t understand routing, without providing any specific points to back up your statement, does not contribute to the discussion.
If you disagree with my proposal, I encourage you to explain specifically where my understanding of routing is flawed. From my perspective, your responses have been vague and have not addressed the core issue I raised. If you’re open to constructive dialogue, I’d be happy to discuss the technical details further.
