Scenario:

• Headquarter (HQ) connected (MPLS VPN) to some branch sites.
• In some of the branches, a Check Point UTM-1 Edge X (SofaWare) sits between the wireless and wired networks, enforcing security policies between them.
• The two networks are bridged together (Layer 2) by the firewall.
• The wireless LAN is used by some kind of next gen Barcode Scanner: an embedded device with Windows CE .NET 4.2, also able to act as a Terminal Services client.

Customer wants to install some software on the scanners, downloading it from a shared folder residing on one of HQ servers. I add the necessary (and temporary) rules on the firewalls, but the folder still cannot be reached. Windows CE complains that “The network path was not found” but the rules look good.

Luckily, the Edge firewalls provide a packet sniffer, allowing us to further investigate the issue. Just connect to the web based interface of UTM-1/SofaWare, go to Setup → Tools → Sniffer, choose a filter string (using the familiar libpcap/tcpdump syntax), select the interface (“bridge”, in my case), and you’re set. Captured packets can then be downloaded to your PC and opened up in Wireshark.

We came up with a bunch of peculiar NetBIOS Name query requests/answers:

Some hostnames, for clarity:

The Barcode Scanner (Client) asks one of the DNS/Domain Controllers in HQ if it is called HQSERVER. But HQSERVER is the server we’re trying to connect to from the Scanner (by means of \\HQSERVER\sharename)! Why in the world the device should directly ask HQDC1 if it is called HQSERVER? Using an unicast NetBIOS query, too? Obviously HQDC1 answers “no, it’s not me” (Requested name does not exist)… The Scanner then broadcasts the same query to its local network segment, but since HQSERVER sits in Headquarter, it gets no answer and generates the error “The network path was not found”.
Turns out that \\192.168.1.20\sharename causes the same dialoque, with a NetBIOS name query that seemingly asks for a server named “192.168.1.20”. It’s as if in Windows CE, UNC paths could only use names, not IP addresses.

Well, the Customer didn’t have enough time for me to properly solve/understand the issue but we worked around it by:

• Assigning a static IP to the Windows CE device.
• In the TCP/IP settings of Windows CE, use 192.168.1.20 (HQSERVER – where the shared folder is hosted) as DNS and WINS server.
• Copy the needed files from the network share and revert back to DHCP.

Step two makes the Client send NetBIOS name queries to HQSERVER instead of HQDC1. This allows shared folder access to work.