SMB Share shows "masked" IP address

Fedora 41 workstation, latest patches

Hi there,

if I connect to my TrueNAS instance via smb protocol, the connection IP is “masked” as the Default route (e.g. 10.0.0.1) rather than the assigned IP (e.g. 10.0.0.200) of the workstation. If I dual boot into Windows and connect to the same share, it is correctly shown as the assigned IP. (add: Linux and Windows both get the same IP by the DHCP)

It worked a couple of days ago, let’s say a week ago. Rebooting router, managed switch, truenas and fedora multiple times has not worked.

Has anyone an idea, what is happening? I thought the error was on truenas side, or the switch or the router, but as my dual boot windows is working fine, it must be fedora.

Would love to get some hints!

Are the packets being forwarded through your 10.0.0.1 router? Is the source IP of the Linux OS in a different subnet? Maybe sudo traceroute -T -p 445 <TrueNAS-IP> would show how the packets are being forwarded?

Hey and thank you for your ideas!

Router interfaces have the IPs 10.10.5.1 and 10.10.9.1, workstation is 10.10.5.250 and TrueNAS is 10.10.9.10.

Traceroute seems to be ok: executed from workstation:

traceroute to 10.10.9.10 (10.10.9.10), 30 hops max, 60 byte packets
 1  truenas (10.10.9.10)  1.804 ms  1.562 ms  1.520 ms

So your router is multi-homed?

I take it the Windows OS has a 10.10.9.x IP and the Linux OS is 10.10.5.250? If so, and the subnet mask is x.y.z.0/24, then that might explain what you are seeing – your Linux OS is connecting from a different subnet and therefore it must pass through the router (and your router is configured to do some sort of network address translation).

If your Linux OS and TrueNAS server are on the same subnet, then your Linux OS should be able to connect directly without going through the router.

An explanation of CIDR notation can be found here: Classless Inter-Domain Routing - Wikipedia

My router is single-homed. My network setup is:

vlan1: Default 10.10.1.0/24
vlan200: Trusted 10.10.9.0/24
vlan201: Isolated 10.10.5.0/24

Windows and Linux get the same IP through KeaDHCP on OPNsense.

One addition: If I smb://10.10.5.2/ to TrueNAS (it has a Management IP) then it does not work either.

And it worked since about 3-4 days ago :frowning: The last update must have changed something, I just dont know where to look.

dnf history list and dnf history info <transaction-id> might provide some clues about what packages were updated recently and which ones might be responsible for the change in behavior. Other than maybe the new randomized MAC address policy though, I don’t know what might cause that sort of change.

Ok, thank you very very much though for your time!

No problem. :slightly_smiling_face: You might double-check the routing rules from both Windows and Linux to see if there are any significant differences there. On Linux, use ip route. I’m not sure what the Windows equivalent is, but there should be one.

Is that /25 a typo? If not, it means 10.10.5.[0-127] is a separate subnet from 10.10.5.[128-255]. So if your Windows OS is configured with an IP of 10.10.5.x/24 but your Linux OS is configured with 10.10.5.x/25, then that could also cause the different routing behavior, even if they both use the same source IP address (assuming the TrueNAS server and the OS IP addresses are on different sides of that /25 divide).

Ups typo, corrected it!

1 Like

Try capturing the relevant traffic on the client:

sudo tcpdump -enni any tcp port 445
2 Likes

THANK YOU VERY MUCH!

I did diagnose the problem with your command. It was Tailscale, so @glb was thinking in the right direction. There was some kind of translation trough the tailscale tunnel and the smb server only saw the router IP. My router advertises tailscale routes and this messed up the smb connection. I switched off Tailscale and voila, my IP is correct again …

Again, thank you very much!

2 Likes