Limiting bound IP addresses

[ptyork]

I'm experimenting with network segmentation and isolation. I currently have one physical interface (ens18), a bridge containing only that interface (br0) with a primary IP and an alias IP (lets call primary:10.0.0.10 and alias:10.0.0.11) as well as a VLAN (call it 10.30.30.30). Couple of questions.

1) Maybe a bug. Maybe a feature. But the list to restrict the bound IP addresses for the GUI, NFS and Kubernetes only show 10.0.0.10 and 10.0.0.11, but not 10.30.30.30. However, all three IP address options are shown for SMB. And at least for the GUI, I can select the 0.0.0.0 wildcard and have the GUI available on 10.30.30.30, but I can't restrict it to, say ONLY the 10.0.0.10 and 10.30.30.30. I assume the same applies to NFS and the Kubernetes Node IP, but I've not tested it.

2) Are there any strategies for getting greater flexibility/granularity with this? Maybe I want to be more restrictive with some SMB shares than with others. Or say I want Plex to be available on 10.30.30.30 and 10.0.0.10, but have all other apps restricted to just 10.0.0.10? And perhaps to have Traefik listening on all three? I know this kind of thing is possible using docker (creating multiple networks and assigning containers to one or more of them), but I don't even know if it is possible in the Kubernetes world, much less if there's a best practice for it on TNS. Any thoughts?

Thanks!

 

[sretalla]

1) Maybe a bug. Maybe a feature. But the list to restrict the bound IP addresses for the GUI, NFS and Kubernetes only show 10.0.0.10 and 10.0.0.11, but not 10.30.30.30. However, all three IP address options are shown for SMB. And at least for the GUI, I can select the 0.0.0.0 wildcard and have the GUI available on 10.30.30.30, but I can't restrict it to, say ONLY the 10.0.0.10 and 10.30.30.30. I assume the same applies to NFS and the Kubernetes Node IP, but I've not tested it.

I would throw a guess in the direction of the GUI only wanting to hook to interfaces or bridges... could you not add a bridge to your VLAN and add the address to the bridge instead (I think that's the correct setup anyway)?

For SMB and NFS, those are services coming from external projects, so there will be limitations on how they work coming from outside of TrueNAS.

2) Are there any strategies for getting greater flexibility/granularity with this? Maybe I want to be more restrictive with some SMB shares than with others.

I don't know that the freedoms of choice you're looking for are going to be possible in the way that you hope. A lot of things would have to change to align in the required way to give you what you want, but the pace of change (and the priorities of those changes) is very different for each component.

The individual apps often have methods of IP-based access control, so maybe consider those.

You can do a lot with an external security tool like a firewall to make your intentions a reality, so I would recommend focusing your efforts on that if you really need those controls now.

 

[ptyork]

I would throw a guess in the direction of the GUI only wanting to hook to interfaces or bridges... could you not add a bridge to your VLAN and add the address to the bridge instead (I think that's the correct setup anyway)?

Good guess, but I get the same behavior after adding a bridge to the VLAN. Still only shows the br1 IP's, not the (new) br20 one. Same behavior, though. I can access it on the VLAN IP as long as I specify the 0.0.0.0 wildcard. I'm guessing it's just a simple bug. I'll go ahead and report it.

 

[ptyork]

Or maybe I won't. Atlassian doesn't seem to let me report bugs...can't even see them at all after I log in. Oh well.

 

[anodos]

Is the VLAN interface IP allocated via DHCP? Both SMB / NFS bindip choices are generated using same middleware call. NFS is passed additional parameter to limit to only static IPs. Historically we've had problems with users who hard-code addresses via DHCP and then file bug tickets against the service when the IP address for server changes (so that's probably why NFS got an additional filter).

 

[ptyork]

Is the VLAN interface IP allocated via DHCP? Both SMB / NFS bindip choices are generated using same middleware call. NFS is passed additional parameter to limit to only static IPs. Historically we've had problems with users who hard-code addresses via DHCP and then file bug tickets against the service when the IP address for server changes (so that's probably why NFS got an additional filter).

Yep! I was just experimenting so let the DHCP server do its thing. I'll try it with a static IP...

...and it worked. GUI, NFS, SMB and Node IP all now showing all options. Obscure, but I guess it'd rarely come up in a real world scenario since assigning a server IP via DHCP is...rare. :) Thanks.

I'm assuming @sretalla's statements on granular address binding for Kubernetes is correct. It appears at least from the GUI that you can select ALL or ONE address to listen on, but not 2-of-3. And there's no easily accessible way of creating something equivalent to custom Docker networks (w/ bridges and IP VLANs) to allow individual apps to listen on specific IPs. My (very) novice brain is assuming that Kubernetes would require multiple Nodes to accomplish this. And that would further require assigning app-pods to specific nodes. Which would entail exposing the complexity of the load balancer. WHICH is likely well beyond the scope of an "easy-to-use" GUI...

Thanks again!