VLANs and subnets and SMB1 oh my
-
I don't know if this is the correct sub forum, or even the right forum for that matter, feel free to move this somewhere more appropriate, I'm hoping someone can help explain some network issues that have me vexed.
We have some old, expensive operational technology devices that have very old Windows OSes running on them -- Windows 95, XP, 2000, 7
We have files that we have to write to shares on these machines. The Win 95 shares, of course, are SMBv1. Before now, we had one big /22 subnet, all the computers in our domain and the OT devices were part of that same subnet. I am in the process of segmenting the network and only allowing the traffic that is required to get the job done.
So, I created VLAN 110 - Operation Technology VLAN. I also create VLAN 111 that is for a middle-man server. There is a 3rd VLAN 112 where only a few managers' computers are. 112 has SMB2/3 access to shared folders on the server in VLAN 111. VLAN 111 has some software on it that syncs these folders to folders on the Win95 computers. Only this server can access the OT equipment in VLAN 110, and only the computers in 112 can access the shares on the 111 server.
All 3 of these subnets have gateways on pfSense router 10.10.10.1, 10.10.11.1, and 10.10.12.1 (same physical interface with tagged vlans. I have the rules in place to allow TCP 139,445 from 10.10.11.0/24 to 10.10.10.0/24. Shares on the 2000 and up machines have not presented a single problem. However, I'm having a lot of trouble with the Windows 95 shares (SMBv1).
The server (Server 2019 Datacenter) is running on VMWare ESXi 6.7. I have enabled the SMBv1 client, set LMCompatibility lvl to 1, allow insecure guest access, etc. Here's where things start to get interesting. If I put my laptop (Windows 10) in VLAN 111 it can access the shares on the Windows 95 machines. So I start wiresharking the traffic on my laptop and comparing to the Server 2019 traffic. I'm admittedly not very skilled at analyzing this data. But basically what I'm seeing is, on both of them, they start out with SYN, RST ACK to 445, and for some reason 80. Then a SYN on 139, which usually gets a SYN ACK.
After the acknowledgement, the Windows 10 machine continues to setup and SMB session. The Server 2019 looks like it does a FIN ACK and never establishes SMB communication.
If I add a network interface to the Server 2019 VM and put it in the OT VLAN 110, and give it an IP in the 10.10.10.0/24 subnet with NO gateway, suddenly the SMB1 connection works. But wiresharking on the 10.10.10.x interface I don't see any SMB traffic, so I wireshark back on the 10.10.11.x interface and there it is! But now it works!??? The ONLY traffic I see on the 10.10.10.x interface is a bunch of ARP broadcasts and an occasional SSDP packet.
-
Just an idea ?
Could it be WINS / Netbios name resolution ??
Your devices can see/resolve when on same subnet , but not on separate lans ?/Bingo
-
@bingo600 said in VLANs and subnets and SMB1 oh my:
n same subnet , but not on separate lans ?
That would make sense, but why does my Windows 10 laptop, when put in that 10.10.11.x network vlan 111, why does it successfully make the connection?
But let's say it is a Netbios name resoltion issue. Is there something I can do in pfSense to have this work without dual NICs on the VM?
-
just use the fqdn to access your resource..
-
@johnpoz
Windows 95 computers aren't joined to our domain, there is no FQDN. I can assign them a name in DNS and use that, but it makes absolutely no difference. -
Joining to a "domain" has nothing to do with a fqdn..
Windows 95 machines understand dns just fine ;)
L2 discovery doesn't work when your not on the same L2.. Be it broadcast, multicast, LLDP, WSD.. etc.. If you want to maintain old school OSes like that - then setup WINS ;) for them to resolve netbios names across vlans. Thats how it was done before ;) Getting rid of that crap that was was wins was the best thing ever! Gawd that was a mess to maintain across multiple sites..
Or just use dns to resolve what you want via a fqdn. Or just use the IP ;)
-
@johnpoz
Ok, so I have a workgroup computer named XYZ. What is it's FQDN? It doesn't really have one. Again, I can put an A record on my DNS server and use the name instead of an IP, but it resolves NOTHING. What does the FQDN have to do with the inability to connect to an SMBv1 share from another subnet?"Or just use the IP"
What do you think we're doing? How else would I be accessing it?
-
@dlogan said in VLANs and subnets and SMB1 oh my:
What is it's FQDN?
Whatever you want to be!! Use the same thing your AD is using.
You resolving a name to an IP has zero to do with SMB be it 1, 2 or 3.. But no you can not use discovery across vlans.. your windows 95 box isn't going to be able to broadcast for server, and expect an answer because that doesn't cross L2..
-
@johnpoz
So we've established that I can make an A record and use the name and it doesn't do anything, so I don't think FQDN has anything to do with this issue. -
What issue? You say it works when you use IP.. So your problem is name resolution.. And again old L2 discovery methods do not work across vlans... Look up that up in the old MS docs - they had you run wins.. to resolve the host name to the ip.
-
@johnpoz said in VLANs and subnets and SMB1 oh my:
me to an IP has zero to d
No I did not say it works by IP, I've been using IP since the beginning.
-
Well then open the ports on the firewall.. No old school OSes like windows 95 do not use the 445 port.. They used old school 137-139 ports for file sharing.. ie smb..
TCP 137 - SMB over TCP port (via NetBIOS).
UDP 137 - SMB over UDP port (via NetBIOS).
UDP 138 - SMB over UDP port (via NetBIOS).
TCP 139 - SMB over TCP port (via NetBIOS). -
@johnpoz
Nope. All open. Did you read the part where I put my laptop in vlan 111 and it works? But the 2019 server on my ESXi host doesn't? Then it suddenly works when I put a 2nd interface on the VM in vlan 110 but the SMB traffic isn't going out the 110 inteface, it's going out the 111 interface? -
This comes down to resolving name, and access.. Doesn't matter if smbv1,2 or 3..
Then a SYN on 139, which usually gets a SYN ACK.
If you get a syn ack.. You started the conversation and got an answer.
-
@johnpoz said in VLANs and subnets and SMB1 oh my:
You started the conversation and got an answer.
I agree. But the SMB session is never negotiated. On the 2019 VM there's a FIN ACK and nothing happens. On my 10 machine I see the SMB handshaking and the folder opens.
-
@dlogan said in VLANs and subnets and SMB1 oh my:
FIN ACK and nothing happens
That is closing the conversation.
-
@johnpoz
Again, I agree. But why does the 2019 server close the connection and the Windows 10 machine continues on the the SMB protocol? -
You will have to ask windows why it closes the conversation.. Did you auth? I am on a work call currently - but I could fire up smb1 and show it working.. but if the server sends a FIN, it is closing the conversation..
Can you post your sniff from your client, and then a sniff from the server at the same time will show you if any traffic is not passing the firewall.
-
It looks to me like the client side (the Server 2019 VM) is closing the connection. The FIN is sent from the client to the server.
Where's a good place to upload the captures and link them here.
The server side (Win 95 machine) is going to be difficult. I can't install anything on it. I might have to setup a mirror on my switch and get the packets from there.
-
Ok, 1st capture, after a reboot, only 1 nic is enabled on the Server 2019 VM. I start a capture to host 10.10.10.12 and attempt opening the folder using \\10.10.10.12\002\ it fails: trackhound-to-002-nic1-vlan111-during-fail.pcapng
2nd capture on the same interface, after enabling a 2nd NIC with IP 10.10.10.2 in the same VLAN as the 10.10.10.12 machine. This time the connection to \\10.10.10.12\002\ is successful: trackhound-to-002-nic1-vlan111-during-success-after-enabling-nic2.pcapng
Another capture going on at the same time as the success but capturing all traffic on the 2nd NIC: trackhound-nic2-vlan110-during-success.pcapng
