Configuring Multiple RJ45 Ports with Unique IPs on TrueNAS Scale

Dear Community,

I am using the latest stable version of TrueNAS Scale and need assistance configuring my network setup. My system has 5 RJ45 ports, 2 of which are connected to my Ubiquiti switch. My network is 10.0.0.0/20, and I want to assign the following static IPs to the connected ports:

  • Port 1: 10.0.0.19
  • Port 2: 10.0.0.20

Unfortunately, I am running into issues:

  1. TrueNAS requires me to assign the /20 subnet to each interface, and I can’t seem to configure two IPs in the same subnet on different interfaces.
  2. When I set the ports to DHCP, they automatically pick up the /20 subnet, but if I manually configure them with /30, I lose access to TrueNAS.
  3. I need each port to have a distinct IP address to use them independently, such as for containerized applications. For example:
  • Using 10.0.0.19 for Pi-hole as the DNS server without needing to include a port (e.g., 10.0.0.20:8080 wouldn’t work for DNS).

My goal is to:

  1. Assign unique IPs to each of the two RJ45 ports connected to the switch.
  2. Use these IPs directly for specific applications, ensuring easy port assignment and accessibility.

How can I configure TrueNAS Scale to achieve this? Are there specific settings, VLAN configurations, or workarounds I need to implement to resolve this issue?

Thank you in advance for your help!

Best regards,
Ricardo

That’s correct; this is an invalid configuration:

The apps system does not currently support this.

3 Likes

You can create a macvlan for the apps so they have their own IP, but they will all come out of the same physical interface.

Dear Dan,

Thank you for your response and for pointing me to the resource about multiple network interfaces on a single subnet. However, I must respectfully disagree with the assertion that this setup is inherently invalid.

Counterpoints:

  1. Common Practice Worldwide:
    Configuring multiple interfaces on the same subnet with unique IPs is a widely adopted standard in networking. ISPs and enterprise networks globally use this approach to manage redundancy, load balancing, or specific application assignments. It’s essential to note that I am not attempting to assign the same IP to multiple interfaces—each interface has a different IP within the same subnet. This practice is valid and supported by most networking stacks and devices.

  2. TrueNAS Behavior and Access Anomaly:

  • If this configuration were genuinely invalid, how is it that TrueNAS can successfully access the network via an IP assigned through DHCP by my internal router (which operates within the /20 subnet)?
  • However, when I attempt to configure the same IP statically on TrueNAS, it fails. This inconsistency suggests that the limitation is not a network standard issue but rather a software design or implementation oversight in TrueNAS.

  1. Use of Specific IPs for Applications:
  • On my original question about assigning these IPs directly to specific applications, the response was: “The apps system does not currently support this.”
  • However, this statement is inaccurate. TrueNAS does, in fact, support assigning applications to specific interfaces and IPs. I’ve attached a screenshot demonstrating this capability. The apps system allows binding containers to specific interfaces, so the real limitation seems to be on the network configuration side, not the application assignment side.

  1. Complexity and Usability:
  • While I understand TrueNAS’ position on avoiding potential conflicts, prohibiting a valid configuration unnecessarily complicates things for users with advanced networking needs.
  • Disallowing this flexibility forces users into workarounds like creating VLANs or using NAT/port-forwarding, which is over-engineering for many straightforward use cases.

Request for Assistance:

Given that this setup is valid from a networking perspective, is there a specific technical reason TrueNAS cannot support it? If the software is designed to avoid potential pitfalls, could there be an advanced option or override to enable this functionality for experienced users?

Thank you again for your time and support. I look forward to your insights.

Best regards,
Ricardo

I’m not interested in arguing the point with you. More knowledgeable people than I have explained why it’s invalid, and that’s why TrueNAS doesn’t support it. Take it up with the devs if you like, but I expect they’ll tell you the same thing. If you’re able to receive IP assignments via DHCP for two interfaces within the same subnet, that’s likely a bug.

I expect what they use instead is what they should be using, which is a proper link aggregation protocol. TrueNAS supports those just fine (as described in the link I shared above).

1 Like

@ricardo.gomes
The configuration you want is NOT valid. You assertion that it is is just wrong. @dan is completely correct.

Just to add my 2p worth and to support @dan
[Retired network engineer]

1 Like

Dan,

I appreciate your input, but I must clarify: my explanation is based on facts, not conjecture. What you’ve described as a “bug” is, in reality, a software limitation deliberately implemented to restrict configurations that are entirely valid in standard networking practices.

TrueNAS is designed to prevent what it considers “conflicting configurations,” but in doing so, it does not prevent logical setups like assigning one static IP to TrueNAS and another directly via my network—both on the same subnet. This isn’t a bug but a design decision that unnecessarily limits flexibility.

As for assigning different IPs to containers, this is neither a bug nor an unusual request. It is a standard networking requirement, avoiding the need for excessive port forwarding for every service. I’ve worked with enterprise networks and ISPs for over 15 years, and I’ve never encountered such an overly restrictive approach. Limiting valid configurations only complicates network management unnecessarily.

I encourage you to revisit the technical reasoning behind this restriction and evaluate whether it truly adds value for the user.

Best regards,
Ricardo

NugentS,

Thank you for sharing your perspective, but I must strongly disagree with your explanation, as it lacks practicality for real-world use cases.

You suggested using link aggregation protocols, but this solution is entirely irrelevant to my scenario. For example:

If I want to run Pi-hole as a DNS server on 10.0.0.19 while also hosting a web server on port 80, how would link aggregation solve this?
Port forwarding is not a viable solution in this case, as DNS servers require direct IP addresses (e.g., 10.0.0.19), not IP+port combinations like 10.0.0.19:8080.

The configuration restriction imposed by TrueNAS is illogical and lacks any technical merit. Locking such configurations without providing a sound alternative is, frankly, counterproductive. Networking standards support having multiple interfaces with different IPs on the same subnet, and these restrictions serve no logical purpose other than complicating user workflows unnecessarily.

I urge you to reconsider the reasoning behind this limitation and its impact on practical use cases.

Best regards,
Ricardo

I’ve just created a feature request because this restriction makes absolutely NO SENSE: Request for Re-Evaluation of Networking Configuration Restrictions.

Feel free to join the discussion and support the request if you agree this needs to be addressed!

I am disinclined to acquiesce to your request, largely because you’ve demonstrated no understanding of the very valid reasons for this restriction–which, for the third time, are explained in detail in the resource I linked to. And secondly, because it isn’t my decision in any event, so there’s little to be gained by my “revisit[ing] the technical reasoning behind this restriction.” As I said, I’m not in the least interested in arguing the point with you–argue with the devs if you like.

Different IPs for different apps do make some sense, though it’s rare that there’s a true need for them (in almost all cases, an ingress reverse proxy is a much better solution). And AFAIK, that’s already on the roadmap.

1 Like

Dan,

Thank you for your response, but I feel compelled to clarify the situation one final time.

  1. Understanding of the Restriction:
    I have thoroughly reviewed the resource you linked and fully understand the arguments presented there. However, they do not apply to my specific use case. The restriction you are defending assumes that multiple interfaces on the same subnet inherently cause routing conflicts or other network issues. This is not the case when properly implemented with distinct static IPs per interface.Enterprise-grade networking equipment and even other operating systems allow such configurations without issue because they rely on standard networking principles. The restriction imposed by TrueNAS is a deliberate design decision—not a technical necessity—intended to prevent potential misconfigurations, but at the cost of limiting valid setups.

  2. Decision Authority:
    You are correct that this decision ultimately lies with the developers, which is why I have already created a feature request to address this limitation (as you suggested). My earlier comments were directed at fostering an informed discussion, not arguing for the sake of it.

  3. Ingress Reverse Proxy:
    While ingress reverse proxies have their use cases, they are not a one-size-fits-all solution. For example, DNS services like Pi-hole require direct IP access, not a port-forwarded or proxied connection. Suggesting a reverse proxy as the “better solution” disregards these practical requirements and adds unnecessary complexity to what should be a simple configuration.

  4. Different IPs for Apps:
    I appreciate your acknowledgment that different IPs for apps make sense. However, labeling this as a “rare need” is dismissive of the many scenarios where this is not only practical but necessary. Modern workloads often require isolation of services by IP for security, redundancy, or simplicity.

In conclusion, I have escalated this issue to the developers, as you advised, and will await their response. I appreciate your engagement thus far, but unless there are new technical points to address, there is no further value in continuing this debate here.

Best regards,
Ricardo

To my knowledge, their is exactly 1 Unix OS that supports multiple NICs & IPs in a single subnet, that is Solaris. (And probably it’s Open Source derivatives, like Iluminos.)

Beginning with Solaris 10, Sun introduced IPMP, Internet Protocol Multi-Pathing, a switch independent method for high availability. Meaning it works across 2, (or more), switches, which LACP generally does not. (IPMP also works with both LACP & tagged VLANs.)

Solaris IPMP allows 2, (or more), IPs in the same sub-net to be on different NICs AND still do the right thing in processing out bound packets. I know this works because I both implemented it, and thoroughly tested it. We had a Solaris 10 file server that had both NFS & SMB clients, and I separated traffic by IP / DNS entry.


However, while people can put multiple IPs in the same sub-net on different NICs, routing out bound packets is the issue. So it does not work, except in specialized situations like Solaris 10 / 11 IPMP.
Now this does not have anything to do with VIPs, extra IPs on a single NIC. VIPs are routinely used for applications so that they can be moved to another server. (While the server's management IP remains on the server, well for management purposes...) IPMP also supports VIPs.
1 Like

Arwen,

Thank you for your detailed response. While I appreciate the historical and technical background you’ve provided regarding Solaris and IPMP, I believe there’s been some misunderstanding about the actual issue and use case I’m addressing. Let me clarify:

1. Multiple NICs with Different IPs in the Same Subnet

The ability to assign multiple IPs to different NICs within the same subnet is not exclusive to Solaris or its derivatives. Most modern operating systems (e.g., Linux, BSD variants, and even Windows) allow this setup, provided the network is configured correctly. The key lies in ensuring proper routing, which can be achieved by setting explicit source-based routing rules.

I’m not suggesting TrueNAS should automatically handle routing ambiguities for such configurations. Instead, I’m advocating for the flexibility to configure this valid setup manually, as required in specific use cases. Users with advanced networking knowledge should have the option to implement these configurations if they understand the responsibilities that come with it.

2. Outbound Routing Challenges

You mentioned that routing outbound packets is the issue. This is true for improperly configured setups, but it is not an inherent limitation of having multiple NICs with different IPs in the same subnet.

  • With source-based routing (e.g., ip rule and ip route in Linux), outbound traffic can be reliably routed through the appropriate interface. This is a well-established solution that does not require Solaris IPMP or similar specialized mechanisms.

TrueNAS’ current design precludes this entirely, even when users have the expertise to manage such configurations manually. This limitation creates unnecessary barriers for advanced use cases, such as isolating specific services by IP for DNS, web hosting, or containerized applications.

3. Not About VIPs

I agree that VIPs are commonly used for failover and high-availability setups, and they serve a distinct purpose. However, this discussion is unrelated to VIPs. My request focuses on the ability to assign distinct IPs to multiple NICs within the same subnet for application isolation or service separation, not for failover or HA scenarios.

4. Real-World Relevance

The use case I’ve described is not theoretical. For instance:

  • Running Pi-hole as a DNS server requires a direct IP address (10.0.0.19), while other services (e.g., web server) may use a separate IP (10.0.0.20) on the same subnet.
  • Assigning these services to different NICs provides logical separation, avoids port conflicts, and simplifies management.

Blocking this configuration entirely, as TrueNAS does, is a design decision that limits flexibility, rather than a technical limitation.

Conclusion

While I respect the historical context of Solaris and its IPMP capabilities, the restriction in TrueNAS is not a matter of what’s possible in modern networking—it’s about providing the flexibility to implement valid configurations when needed. I hope this clears up any misunderstanding about the issue I’m addressing.

Thank you again for engaging in this discussion.

Best regards,
Ricardo

You basically killed the feature request with the words “I’m not suggesting TrueNAS should automatically handle routing ambiguities”.

TrueNAS SCALE or Core is an appliance. While it can do many things, it needs to be “bullet proof”, or as close to it as possible.

I once saw in a full on production data center have serious problems due to asymmetrical routing. It was killing our network for several hours each day. Because the traffic was not coming back the same route, it was being broadcast across every single Ethernet port the down stream switch had active. The bigger servers handled uni-cast traffic that was not for them, by simply dropping the packets. But, the smaller servers dropped off the network for hours because they could not handle the load. Really bad. I was the one who had to force network to fix their problem, not a good day.

However, that said, you can certainly implement anything you want under the hood. Just make sure you have a clear documentation on what you do, and any scripts should be stored in such a way that they survive a TrueNAS SCALE update.


To be clear to others, I know about source routing and static routes for interfaces, (verses IPs / routers). They can do odd things in Linux. But, I have never seen it used in production, in my 30 years as an Unix SysAdmin. Nor the 15 years before that in software development. Maybe my employers simply did not need such...
1 Like

Brings me back to the days before VMs. And trying to get my devs/manager to understand that yes, you can have more than 1 NIC on the same VLAN but it’s just not going to behave the way you want it. Linux happily would do it, but most things on the other side of the wire didn’t like a different IP (the NIC with the default route) answering on behalf of the other one :wink:

Sorry @ricardo.gomes but you are wrong. The configuration you are asking for is invalid and whilst some OS’s will allow the config - it doesn’t work the way you think it does

I suspect you should be looking at setting up a bridge for the second interface and assigning IP’s to containers / VM’s on that bridge

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

Craig_L,

Thanks for sharing your perspective. I understand where you’re coming from, but I think it’s important to separate outdated perceptions of networking challenges from modern, practical implementations.

1. Modern Networking Standards

Yes, back in the day, having multiple NICs on the same VLAN could cause confusion, especially with routing ambiguities. But modern Linux systems handle this scenario gracefully with source-based routing or explicit static routes. Proper configuration ensures that each NIC is tied to its respective IP and responds accordingly—no “NIC with the default route answering on behalf of the other.”

This is not just theoretical. Competitors like Synology, Unraid, and OpenMediaVault allow multiple NICs with distinct IPs in the same subnet because they rely on these same modern networking standards. Users configure them without issues, even in smaller setups or lab environments.

2. The Other Side of the Wire

If devices “on the other side of the wire” have trouble with this setup, it’s not because of the configuration itself but likely due to incorrect routing or ARP cache issues. Again, this is solvable with modern tools—something Linux has supported for years.

For example, in a controlled internal network, there’s no reason why:

  • NIC 1 with 10.0.0.19 cannot handle DNS (Pi-hole).
  • NIC 2 with 10.0.0.20 cannot handle web traffic (e.g., Jellyfin).

When properly configured, each service operates independently without stepping on the other’s toes.

3. The TrueNAS Limitation

The issue here is not about whether this setup can work—it clearly can and does on many platforms. The issue is TrueNAS unnecessarily limiting this configuration entirely. While I understand the aim for “bulletproof” simplicity, this restriction removes flexibility for advanced users who know exactly what they’re doing.

If other platforms like Synology, Microsoft, and Unraid allow this without trouble, why shouldn’t TrueNAS SCALE? If the product is named “SCALE,” it should scale to handle diverse use cases, not lock down features that are already standard elsewhere.

Let’s not let old assumptions about networking prevent TrueNAS from growing into the competitive, flexible platform it has the potential to be.

Best regards,
Ricardo

NugentS,

Thank you for your response, but I respectfully disagree with your assertion that this configuration is “invalid.” The setup I am describing—assigning multiple interfaces with unique IPs within the same subnet—is both valid and widely supported in modern networking, provided it is configured correctly.

1. This Configuration is Not Invalid

The claim that this configuration doesn’t “work the way you think it does” is inaccurate. With proper routing and source-based rules, this setup functions as intended:

  • NIC 1 with 10.0.0.19 handles DNS (Pi-hole).
  • NIC 2 with 10.0.0.20 handles web services (e.g., Jellyfin).

This is not a theoretical or niche use case; it is a standard practice supported by Linux, Windows, Synology, and other platforms. The issue is not the configuration itself but TrueNAS SCALE’s restriction, which prevents users from implementing it—even when they understand how to manage routing.

2. Bridging is Not a Solution

Bridging the second interface to assign IPs to containers or VMs is not an appropriate alternative in this scenario. Here’s why:

  • Port Conflicts: Assigning services to the same IP with different ports (via bridging) introduces unnecessary complexity and doesn’t solve conflicts where services like DNS (Pi-hole) require direct IP access.
  • Security and Isolation: Bridging collapses the separation between interfaces, reducing isolation and flexibility. Assigning distinct IPs to each NIC provides a cleaner and more secure solution.

3. TrueNAS Limitation

TrueNAS SCALE’s restriction on this valid configuration is the problem here. Competing platforms like Synology, Unraid, and OpenMediaVault handle this setup effortlessly because they allow users to configure routing manually if needed. TrueNAS should provide similar flexibility, especially for advanced users managing small, internal networks without requiring VLANs or NAT.

4. Challenge

If this configuration is truly invalid, I’d challenge you to explain why other platforms successfully support it and why it works flawlessly in controlled setups. Suggesting bridging or VLANs as a workaround only adds unnecessary complexity when the desired setup is straightforward and supported by networking standards.

I appreciate the discussion, but I stand by my position: this configuration is valid, practical, and necessary for many use cases. TrueNAS SCALE should aim to enable flexibility, not restrict valid setups unnecessarily.

Best regards,
Ricardo

I am out

This is not an argument I have any interest in continuing.

2 Likes