Arwen,
Thank you for your detailed response, but I feel we are missing the real issue here. Let me address your points directly while posing an important question about practical use cases that TrueNAS currently fails to handle effectively.
1. “Bulletproof” Appliance vs. Flexibility
TrueNAS being an appliance does not justify locking down features that are standard across competing platforms like Synology, Unraid, OpenMediaVault, or even general-purpose Linux-based setups. If TrueNAS wants to carry the name “SCALE,” it should aim to scale both in functionality and adaptability to meet real-world needs.
Microsoft, Synology, and countless other systems allow multiple NICs with unique IPs in the same subnet because this is a valid and often necessary configuration in internal networks. Their approach has not led to the issues you describe because the responsibility for configuring it correctly rests with the user.
If TrueNAS doesn’t specialize in networking (and it doesn’t), why impose these restrictive limitations that serve only to create frustration? Why not allow users the flexibility that every other platform provides and simply document the potential risks for less experienced users?
2. Real-World Use Case: Pi-hole and Web Servers
How would you suggest a TrueNAS user implement this setup:
- A DNS server (Pi-hole) running on IP
10.0.0.19
.
- A web server running on IP
10.0.0.20
for websites, Jellyfin, or other services.
Both services must be on the same subnet (e.g., 10.0.0.0/20
) in an internal network. DNS cannot function via port-forwarding (10.0.0.19:8080
doesn’t work for DNS), so assigning distinct IPs is the logical solution.
What is your suggested workaround for this with TrueNAS? VLANs? NAT? These approaches introduce unnecessary complexity for something that works seamlessly on Synology, Unraid, and other platforms. Why should TrueNAS users jump through hoops for a configuration that others handle effortlessly?
3. Asymmetrical Routing Concerns
You raised concerns about asymmetrical routing causing network issues. These are valid in poorly configured environments or at scale, but they are entirely irrelevant to my use case. In a small-scale, internal network, routing ambiguities simply don’t exist when static IPs and proper routes are configured.
Dismissing the use of source routing or static routes because “you’ve never seen it in production” does not invalidate its effectiveness. I’ve worked in enterprise networking and ISP environments where this approach is used successfully and routinely, especially in isolated internal networks or lab setups.
4. Disconnected from Real-World Needs
Dan, with all due respect, I feel the responses here reflect a fundamental disconnect from the realities of what users need. The inability to assign multiple IPs in the same subnet on different NICs is a limitation that other platforms have resolved long ago. It’s not about whether this is a “common need” in production—it’s about whether TrueNAS can support the flexibility to handle diverse use cases.
If TrueNAS wants to grow as a compelling product and reach the masses, it cannot impose arbitrary limitations that other platforms have already solved. The ability to configure multiple NICs on the same subnet is not an edge case; it’s a basic feature for modern networking.
5. Request for Solution
So, I’ll ask again: How can I achieve this setup on TrueNAS?
- DNS (Pi-hole) on
10.0.0.19
.
- Web server on
10.0.0.20
.
Both running on the same subnet (10.0.0.0/20
) without VLANs or NAT.
If the answer is “you can’t,” then that’s precisely why this feature request exists. TrueNAS needs to support flexible networking configurations to remain competitive.
Best regards,
Ricardo