Dedicated NIC for NFS : asymmetric routing problem : how to force NFS on the NIC from where comes the request ?

[The violonist]

Hello,

I am currently facing an issue with my TrueNAS test setup.

For security reasons, we always separate management & traffic. My test setup has 2 NICs :
* management NIC #A, (SSH & web UI enabled, NFS forbidden), subnet A, name truenas.domain, default GW
* traffic NIC #B, (SSH & web UI not listening, NFS allowed), subnet B, name truenas-nfs.domain

The default gateway is on subnet A.

Problem : When a client mounts a share from truenas-nfs.domain (configured NIC #B), the answer comes from NIC #A via default gateway. And of course our FW blocks the traffic, he hates assymmetric routing.

On Linux boxes, the key is to use "ip rule". But my FreeBSD mastery is far too low... Any help welcome.

Thank you,

 

[Patrick M. Hausen]

Is the client in subnet B? If yes, that's weird. The answer should go to the directly connected subnet if there is one, even with the current state of networking in TrueNAS.
If the client is on any other subnet, then answering via the default gateway is how IP works. Without any special firewall rules like setting next hop and the like. TrueNAS does not support that so you are kind of stuck.

Workaround: NAT traffic to subnet B on your firewall.

IMHO network isolation does not make much sense if the clients are not also divided into separate zones. So for each service that you want to put into a separate subnet, all clients using it should also have a direct connection to that subnet.

 

[The violonist]

Thank you Patrick for your answer.

The client can be on... Many differents subnets. Too much to create one interface per VLAN.

On our Linux in the same situations we managed to use "ip rule" to force the answer to be sent on the interface from where came the request. I was trying to do the same with BSD... Seems to be possible with ipfw, but I am not familiar with this...

Thanks anyway !

 

[Patrick M. Hausen]

It is possible with FreeBSD as is with Linux. But TrueNAS is neither. TrueNAS is a storage appliance with a fixed feature set and you are not supposed to mess with anything not available in the UI.

You don't do "Linux things" on your Qnap or Synology, either ...

Many differents subnets. Too much to create one interface per VLAN.

How many? You know you can create a trunk port with VLANs in TrueNAS? That is perfectly well supported.

Another solution can be to add a static route or multiple routes for all those subnets to your TrueNAS with the IP address of your firewall in subnet B as the gateway. That way you will get symmetric routing.

What you will not be able to achieve with TrueNAS without completely unsupported hacks is one and the same client in VLAN X accessing the UI via subnet A and NFS via subnet B. But that doesn't make much sense, does it? The idea of separation via VLANs is to contain the connections within a certain VLAN. Specifically if your organization has got a policy for separate management networks, then all management stations ought to be in that VLAN and not cross any firewall/router for access. An internal VPN can help with policies like that.

 

[sretalla]

Perhaps what you're really describing here is the need to have a jump host to act as a reverse proxy or remote desktop which is in the management VLAN and can be accessed only by allowed clients from your client VLAN.

You would then allow that host to be accessed via the router on that subnet, so no funky routing would occur since the jump host/proxy would only have one IP on the management net.