Cannot Access SMB on Second Nic After Fangtooth Upgrade

Good Evening Everyone,
Long time TrueNas user, first time poster to this forum. I have been having access issues since upgrading to the point release of Fangtooth.

First my UI became inaccessible (which I solved by changing the default route to the subnet of my UI) and now I cannot access any of my shares which are bound to my second NIC that is on a different subnet than the default route.

If I move everything to the same subnet as the default route it works, but otherwise I cannot ping or access SMB, etc.

I’ve tried playing around with static routes but that hasn’t helped at all.

Any idea what the problem is and why it’s just happened now? I’ve had the same config since Scale 23 generation without any upgrade problem ever!

Thanks!

Pretty sure the gui and services can be bound to specific nics and you need a solid default route / gateway. Might have lost some duct tape holding it together during the upgrade.

Go look at your global smb service settings, advanced . See which ip is assigned.

In my case I have two nics with two ip addresses. They’re defined here.

Look in system /general / gui settings too. It lets you define which ip supplies the gui.

I can add my GUI/Mgmt NIC IP to the SMB and that works. The problem is I can’t access it over the other NIC which is what I need for non-admin users on my network.

1 Like

Can ya click add and put another ip in there?

First, you should post an ip a output.

“access it” – SMB or GUI? And how do you want it to be?

I cannot ping or access the share over smb from a client on my network…

What about ip a? System → Shell → ip a.

Is your client connected to the “non-admin” NIC?

Ok I am starting to understand what is going on but not still not sure a) what to do about it and b) why this all just happened after Fangtooth.

I connect to Truenas from different VLANs on my network. I have an Admin VLAN which certain clients live on that access the WebUI, and a User VLAN that the rest of the clients live on that access the SMB. My Admin VLAN has permissions at the router/firewall level to access both.

What appears to be happening here is an assymetric response where I access one interface say 10.1 from 10.3 and because the reply is not going back to a 10.1 interface somewhere the packet is dropped.

If I manually add a static route it works but essentially then I would have to have a gateway for each VLAN I am routing through which seems excessive, and again, this was never a problem before.

ChatGPT suggested changing:

net.ipv4.conf.enp3s0f1.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter= 0
net.ipv4.icmp_echo_ignore_all = 0

But adding these to sysctl in the GUI didn’t seem to do anything. And in the /etc file everything was commented out so I am assuming there is a default override somewhere?

Can anyone explain to me what’s going on and why it changed in Fangtooth?

Don’t wanna be rude, but your entire post looks like it was AI-generated.

You didn’t answer questions. You brought the interfaces’ exact IPs (or better say prefixes) without explaining which one stands for what. You even brought some /etc file nobody had mentioned…

Perhaps I should have just answered with ChatGPT...

1 Like

Not AI. Sorry you weren’t following my comments.

I’ll go seek help elsewhere unless someone else on this forum can help?

I doubt you could gain much help without answering clarifying questions.

Why do you refuse to post ip a output? Is it a secret or what?

This shows that my question was totally legit, as it seems you rely on promiscuous networking mode.

Sorry I didn’t see your client question. Yes the client is on the non-admin nic.

Will post ip an output when I’m back on the server.

Thanks

Here’s the IP A output… I’m sorry I’m not a networking expert so I’m just trying to figure this out as I go along…

To restate my problem for clarity:

2 NICs on TrueNAS:

  1. One should be for WebUI (admin network)
  2. One should be for SMB (trusted user network)

Both live on separate subnets/vlans.

I have an additional VLAN (for example an untrusted wifi network) that certain trusted devices can live on but can also access the trusted user network from. This routing is done via router/firewall rules.

I think what I am learning now is that the issue is that the third untrusted network has a different subnet than either admin or trusted and so the packets are being dropped unless I create a specific static route just for that network. Is that correct?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever

2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

3: enp2s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

4: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 192.168.10.35/24 brd 192.168.10.255 scope global enp3s0f0
valid_lft forever preferred_lft forever
inet6 fe80::7ae7:d1ff:fe7d:5016/64 scope link
valid_lft forever preferred_lft forever

5: enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 192.168.20.35/24 brd 192.168.20.255 scope global enp3s0f1
valid_lft forever preferred_lft forever
inet6 fe80::7ae7:d1ff:fe7d:5018/64 scope link
valid_lft forever preferred_lft forever

12: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 brd 172.16.0.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fdd0::1/64 scope global nodad
valid_lft forever preferred_lft forever

384: br-XXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 172.16.1.1/24 brd 172.16.1.255 scope global br-XXXXXXXXXXXX
valid_lft forever preferred_lft forever
inet6 fdd0:0:0:1::1/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fe80::42:58ff:fe16:450e/64 scope link
valid_lft forever preferred_lft forever

5568: vethXXXXXXXX@if5567: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-XXXXXXXXXXXX state UP group default
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::6c7a:43ff:fe69:9c1b/64 scope link tentative
valid_lft forever preferred_lft forever

Did you set these rules on your switch?

All packets from different subnets are to be dropped/ignored (at least by default). And AFAIK it cannot be resolved with static routes. To pass the package from one subnet to another, you need a machine that is “connected” to both subnets and with enabled IP forwarding (between its NICs). Usually this machine is called a router. IMO, turning TrueNAS into router is not a good idea, but general opinion may vary.


From your post I can see that truenas has 2 active NICs with different subnets – 192.168.10.X/24 and 192.168.20.X/24. So, the next questions are:

  1. Which one is the “admin” subnet – 10 or 20?
  2. What is the address of the client that would have an SMB access?
  3. Did you set any IP restrictions for SMB or WebUI in the truenas itself? You can check this in System → Services → SMB → Edit → Advanced Settings → Bind IP Addresses and in System → Advanced Settings → Allowed IP Addresses. If there is none, don’t set any for now.