RV325 - Samba across vlans

[rob]

I have a digital fax machine trying to save to a NAS.  The conversation happens at the start of the process, and Samba does its Negotiate Protocols, Authentication and Session Setup, but as soon as it begins to write, the RV325 sends a ICMP Redirect (Type 5, Code 1 Redirect for Host) to the NAS and after that the conversation breaks down until the fax machine times out attempting to resend packets (I'm assuming the response never reaches the fax that the NAS received a packet because of the redirect).

VLAN 1 -- 10.10.1.0/24 DCHP server mode 10.10.1.10-150 pool 10.10.1.1 gateway

VLAN 125 -- 10.10.5.0/24 DHCP server mode 10.10.5.100-150 pool 10.10.5.1 gateway

inter vlan routing enabled

NAS is located directly on RV325 on LAN8 Untagged VLAN 1, Tagged VLAN 125.

The Fax is located on a SG500X switch Access Port set to VLAN 125

The SG500X switch connects to the RV325 on LAN4 Tagged VLAN 1, Tagged VLAN 125

Both Fax and NAS are bound by MAC address to IP

NAS 10.10.1.10

FAX 10.10.5.101

Unfortunately I cannot capture any packets at the router or the fax, but I can on the NAS and get look at half the conversation.  From what I can tell in my novice experience with looking at packets (just started for this very reason) is the ICMP comes in to the NAS, and after that it looses the ability to talk back to the fax because it gives it an invalid route.  From what I have read about IMCP Type 5 Code 1 there are certain rules that should be satisfied by the RV325 before it will send an ICMP packet.  The main factor being that the packets are arriving and returning on the same port, but the switch is in LAN4 and the NAS is in LAN8 so there is no shorter route possible so no ICMP packet should have been sent.

Ive attached a zip of a .pcap from the NAS of an attempt by the fax machine.

[Paul Chapman]

Hi -

10.10.1.10 and 10.10.5.101 are on the same subnet, based on the masks provided in your question. (/16 mask makes the network range 10.10.0.0 to 10.10.255.255) If the NAS has a /24 mask, then it will send the traffic to 10.10.1.1 which will reply with an ICMP redirect which would be expected behavior.

Unfortunately, since your masks are mixed, then your inter-vlan routing breaks.

PSC

[rob]

Sorry I typed /16 but I ment /24. ive corrected original post.  mask is 255.255.255.0 on all networks (other vlans for phones and security cameras I don't want inter vlan routing)

[Paul Chapman]

Hi -

I stand by my original comment.  The wireshark you attached shows ARP broadcasts with source addresses in 10.10.1.x, 10.10.4.x, and 10.10.5.x and coincidentally 192.168.1.x.  VLAN separation would prevent the broadcasts from those other networks. (I will admit it's possible that you have a router-on-a-stick configuration and you're overlaying all these networks on the same VLAN.)

Regardless, ICMP redirects which point at an [apparently] different network mean that you have an incorrect mask somewhere in the path, very likely the router itself.

PSC

[rob]

Just read definition of router on a stick, and that's pretty close, except that the NAS is directly plugged into the router and not the switch. the 192 is more than likely from me.  I remote into the network.  Here's a snippit from router config file showing VLANS

[MULTIPLE_SUBNET]
ENABLED=YES
ID="VID=1&IP=10.10.1.1&NETMASK=255.255.255.0&IS_ROUTE=1&DHCP_MODE=1&RELAY=0.0.0.0&TIME=1440&RANGES=10.10.1.10&RANGEE=10.10.1.100&DNS1=8.8.8.8&DNS2=8.8.4.4&WINS=0.0.0.0&TFTPN=&TFTPP=0.0.0.0&TFTPF=&CID=Null&DNSSERVER=3"
ID="VID=25&IP=10.10.2.1&NETMASK=255.255.255.0&IS_ROUTE=1&DHCP_MODE=1&RELAY=0.0.0.0&TIME=1440&RANGES=10.10.2.100&RANGEE=10.10.2.149&DNS1=8.8.8.8&DNS2=8.8.4.4&WINS=0.0.0.0&TFTPN=&TFTPP=0.0.0.0&TFTPF=&CID=Null&DNSSERVER=3"
ID="VID=50&IP=10.10.3.1&NETMASK=255.255.255.0&IS_ROUTE=1&DHCP_MODE=1&RELAY=0.0.0.0&TIME=1440&RANGES=10.10.3.100&RANGEE=10.10.3.149&DNS1=8.8.8.8&DNS2=8.8.4.4&WINS=0.0.0.0&TFTPN=&TFTPP=0.0.0.0&TFTPF=&CID=Null&DNSSERVER=3"
ID="VID=100&IP=10.10.4.1&NETMASK=255.255.255.0&IS_ROUTE=1&DHCP_MODE=1&RELAY=0.0.0.0&TIME=1440&RANGES=10.10.4.100&RANGEE=10.10.4.149&DNS1=8.8.8.8&DNS2=8.8.4.4&WINS=0.0.0.0&TFTPN=&TFTPP=0.0.0.0&TFTPF=&CID=Null&DNSSERVER=3"
ID="VID=125&IP=10.10.5.1&NETMASK=255.255.255.0&IS_ROUTE=1&DHCP_MODE=1&RELAY=0.0.0.0&TIME=1440&RANGES=10.10.5.100&RANGEE=10.10.5.150&DNS1=8.8.8.8&DNS2=8.8.4.4&WINS=0.0.0.0&TFTPN=&TFTPP=0.0.0.0&TFTPF=&CID=Null&DNSSERVER=3"
NUMBER=5

[Paul Chapman]

Hi -

On the RV interface where the NAS is connected, please verify that the port is set untagged for VLAN 1 and that all other VLANs are excluded.  If there's an option for "access" or "trunk", choose access with a PVID of 1.

PSC

[rob]

The RV325 doesn't let one set to access or trunk, only adjust tagged /untagged/excluded. 

I have checked LAN8, and it was set to untagged vlan1, tagged all others. I have changed them from tagged to excluded.  Besides getting rid of some arp traffic, no changes, still getting ICMP.

Included latest pcap.. cleaner without extra arp traffic, but still not right.

[Paul Chapman]

Hi -

Yes. Frames 21 - 24 and 40 show the picture.

• Frame 21: SYN from 10.10.5.101 and sourced from router MAC (correct)
• Frame 22: SYN-ACK from 10.10.1.10 and destined to router MAC (correct)
• Frame 23: ICMP Redirect from router instructing 10.10.1.10 to make a direct connection to 10.10.5.101 (incorrect. Not sure why router sent this frame.)
• Frame 24: ACK from 10.10.5.101 sourced from router MAC (correct, and indicates that router forwarded the traffic as expected)
• Frame 40: ARP from 10.10.1.10 looking for 10.10.5.101 (incorrect. Seems that there's a little delay before NAS realizes it got the redirect message)

I'm guessing that there's something stuck in memory of the router.  Can you reboot it?

PSC

[rob]

Currently its in daily use, can't reboot till after hours.  But yes, Frame 23 is what causes me to scratch my head.  And yes, sometimes after a soft reboot (from GUI) it will work for a bit, and after a while just randomly stop, sometimes after weeks, or sometimes hours later.  RV325 is running latest firmware: v1.3.1.12 (2016-04-27, 10:46:12)

[Paul Chapman]

Hi -

At this point, I would say you need to open a TAC case for resolution.

PSC

[rob]

Sigh, already have one open.  Thanks for looking at it Paul.  I've sent them a few pcaps already and no response. During a call they messed with VLAN and access/trunk settings on the SG500X switch, and then had me after hours update switch to latest FW/Boot Code.  Still having same issues.  I guess I'll set up a box on that network as a syslogger, and see if the router is spitting anything out then that I can track on its log files.