malformed smb2 packet for Server 2016 across a MPLS WAN

asked 2018-03-20 17:58:36 +0000

AlephWolfe
3 ●1 ●2 ●2

Hello,

I am fairly new to Wireshark but I have some experience troubleshooting network issues. I am trying to troubleshoot connecting to an admin share (\servername\c$) across a MPLS WAN connection. According to our MPLS provider there are no ports being blocked on the MPLS WAN. I saved a capture file and it is located at the google drive link below.

When the packets start the SMB2 negotiation I am getting a Malformed Packet followed by a reset of the TCP/IP handshake. I'm not sure if this is an error in Wireshark or if the packet is getting modified incorrectly by a router or other network device.

What is interesting to me is the fact that I can connect to admin shares in the reverse direction. Additionally this error is only happening when the source and destination are Windows 2016 servers. Admin shares on Server 2012 R2 work fine both directions. Connecting to admin shares on the local subnet works just fine using 2 Windows 2016 servers.

10.254.164.166 --> admin share --> 10.254.188.123 Does not work 10.254.188.123 --> admin share --> 10.254.164.66 Works just fine

https://drive.google.com/open?id=1C4m...

I'm using the following filter to show SMB2 traffic: ip.addr==10.254.164.166 and ip.addr==10.254.188.123 and tcp.port==445

I'm leaning towards something being blocked or the traffic being changed to cause the error. But my Senior Network Engineer thinks it is a Server 2016 issue and not network related. I'm looking for some proof that it is a network issue from the information in the packets, but I'm not sure what to look for.

Thank you in advance!

edit retag flag offensive close merge delete

add a comment

answered 2018-03-20 20:42:36 +0000

Uli
1123 ●1 ●25 ●23

For me this looks like a application issue caused by a Riverbed Steelhead:

The capture (I inspected tcp.stream==426) shows no issue up to the TCP layer. Everything is acknowledged fine. There is only problems at the application layer.

The capture looks like it has been taken at the client site (10.254.164.X). The Ethernet source MAC is a Riverbed device. When you take the capture at the server (10.254.188.133) site, chances are pretty high you spot the Riverbed Steelhead also with specific TCP option in use.

=> Check with your Network team if a Riverbed Steelhead is involved in the data flow and if it is running the latest RIOS version. I know of some issues with SMB3 traffic with older versions.

Comments

Yes, you are correct. We have some riverbeds involved in the data flow. That was my first thought of what was causing the problem but I could not prove it. I do see some articles about compatibility with SMB3 and needing to be on a recent version of the RIOS. I now have the proof I need to get the riverbeds updated.

Can you tell me what lead you to follow tcp stream 426? I only know about filtering using the IP addresses, MAC, ports, and protocols.

Thank you so much!

AlephWolfe ( 2018-03-22 13:35:53 +0000 )edit

Glad I've been able to help.

I first filtered for 'ip.addr==10.254.188.123 and tcp.port==445'. This showed the tcp stream 426. Therefore I looked at this stream with 'tcp.stream==426'.

Uli ( 2018-03-22 19:41:58 +0000 )edit

Thanks for that extra information.

AlephWolfe ( 2018-03-23 11:49:55 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

malformed smb2 packet for Server 2016 across a MPLS WAN

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

malformed smb2 packet for Server 2016 across a MPLS WAN edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

malformed smb2 packet for Server 2016 across a MPLS WAN