pfSense 2.7.2 causes unexpected behaviour from Samba 4.16.
-
How are you testing? Is traffic to/from the server being routed through pfSense or is the client in the same subnet?
If it's not being routed then it could only be something like a duplicate IP. Potentially something else that is being routed loading up the NAS.
-
@stephenw10
Both the router and the server are on two VLANS:
[NAS][root ~] > ifconfig em0: flags=8822<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 2c:76:8a:a9:30:18 media: Ethernet autoselect status: no carrier nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> em1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: LAN_MAN options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 2c:76:8a:a9:30:19 inet 172.16.50.4 netmask 0xffffff00 broadcast 172.16.50.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vlan101: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: LAN_PCs options=4600403<RXCSUM,TXCSUM,LRO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether 2c:76:8a:a9:30:19 inet 172.16.51.4 netmask 0xffffff00 broadcast 172.16.51.255 groups: vlan vlan: 101 vlanproto: 802.1q vlanpcp: 0 parent interface: em1 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>The client is on VLAN 101:
C:\Users\TT>ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 172.16.51.23 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 172.16.51.1 Ethernet adapter Ethernet 2: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . :The traffic between the server and the client is not being routed and and there are no
arp movemessages in the logs.When I plug out the router's patch cable, or disable it's port from switch settings, it works. I will go there tomorrow, to conduct further testings. Any ideas?
-
@scilek what cable are you unplugging? If the traffic between your devices were being routed and you pulled the cable on the router then your devices wouldn't be able to talk to each other.
-
With more than one thing multihomed there you could be hitting asymmetric routing. If the client attempts to access the NAS at 172.16.50.4, for example, it will be routed through pfSense but replies will go back directly. You would see traffic through pfSense in the traffic graphs though. Until it stops!
-
@stephenw10 yeah the output of his nas says its multihomed
-
@johnpoz
The traffic between the devices is not being routed. The issue is no that they cannot talk to each other, they definitely can, as pinging continues non-stop. It is just the copy operation that halts, that is, for about 15 seconds, after about 1GB of data has been copied from the NAS. -
@scilek said in pfSense 2.7.2 causes unexpected behaviour from Samba 4.16.:
The traffic between the devices is not being routed
If the devices your moving files between are not routed through pfsense, then pfsense has zero to do with their file copy..
your output from nas shows its got legs in both your .50 and .51 network.. So doing a file copy from either of those networks to the nas would have zero to do with pfsense.. if your doing a copy from a .50 device to a .51 IP on the nas then your asymetrical and yeah could have all kinds of weirdness..
-
Yup but ping works fine and TCP traffic doesn't is a classic symptom of asymmetric routing.
Do you see anything blocked in the firewall logs.
-
@johnpoz
While digging, I realised that the server was somewhat misconfigured:[NAS][root ~] > cat /etc/rc.conf | grep defaultrouter defaultrouter="172.16.51.1"I corrected it then rebooted:
[NAS][root ~] > cat /etc/rc.conf | grep defaultrouter defaultrouter="172.16.50.1"I was hoping that would fix the problem, but it did not.
Then I thought something might change if I blocked the traffic between LAN_PCs and LAN_MAN:
That definitely did help! But why? How? Can I change the default routing behaviour on the router?
-
Because clients are opening connections to the NAS in he other subnet as I speculated.
If they are connecting by hostname how is that resolving?
But the one way to be sure is don't use multihoming on the NAS,
-
@stephenw10 said in pfSense 2.7.2 causes unexpected behaviour from Samba 4.16.:
Because clients are opening connections to the NAS in he other subnet as I speculated.
Well, yes. Appreciated.
@stephenw10 said in pfSense 2.7.2 causes unexpected behaviour from Samba 4.16.:
But the one way to be sure is don't use multihoming on the NAS
I kind of have to. I have similar setups that work flawlessly; but none are v2.7.2.
@stephenw10 said in pfSense 2.7.2 causes unexpected behaviour from Samba 4.16.:
If they are connecting by hostname how is that resolving?
That is the question on my mind.
-
You could add floating rules to just pass the traffic even if it is asymmetric:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.htmlBut I prefer to avoid that if at all possible though. It almost inevitably ends up with other issues in the future. It will be confusing to anyone else looking at it later.
