Windows File Sharing Intermittent Timeout over MetroAreaNetwork(OPT1)
-
Brief Description: Windows and Mac clients lose connections to remote Windows 2000 Server shares over private circuit (Metro Area Network)
Network Layout:
The private circuit has been tested with both a point to point T1/DS1 and a 10Mbps private synchronous DSL circuit between both locations. The original circuit previously used an AdTran router at each location (illustrated as "Old:"). We are hoping to replace the AdTran routers and private T1/DS1 with pfSense routers and the private 10Mbps DSL circuit.Network ASCII diagram:
Old: LAN1 –---------------- AdTran ----- <t1 circuit=""> --- AdTran ------------------ LAN2
Test1: LAN1 --- pfSense ------------------ <10Mbps Circuit> ------------------ pfSense --- LAN2
Test2: LAN1 --- pfSense --- AdTran --- <t1 circuit=""> --- AdTran --- pfSense --- LAN2Latency between pfSense routers is approximately 8ms when using the 10Mbps DSL circuit, and about 6ms when using the T1+AdTrans circuit
Hardware Used:
Servers = Compaq DL360 G2 (dual 1.4Ghz PIII w/ 512MB ram)
NIC WAN = On-Board Brodcom Gigabit (bge1) - Separate DSL circuit to ISP [not impacting this situation]
NIC LAN = On-Board Broadcom Gigabit (bge0)
NIC Metro(OPT1) = Sun Happy Meal Ethernet (hme0) Quad-Port 10/100 64-bit PCI card in a PCI-X 64bit slotSoftware Version:
pfSense 1.2-RELEASETraffic Shaping:
Problem occurs both with and without Traffic Shaping enabled.Firewall:
Both MAN1(OPT1) and LAN interfaces on both pfSense routers have been given 'any to any' allowances as the top rule.MTU:
MTU Settings has been left as defaultOther Protocols:
Does not seem to functionally impact other protocols such as ICMP, FTP, HTTP, SSH, or SIP traffic. At least nothing has been observed or reported thus far.Detailed Description of Windows File Sharing Problem:
Affects both the TEST1 and TEST2 network diagrams. The Original OLD network diagram does not use pfSense and does not have the following problem:File server is running Windows 2000 Server. There are no problems when LAN1&2 use the AdTran routers as their default gateway, and traverse the private T1 (as illustrated by "Old:"). When using pfSense as their default gateway, LAN1 MS FileSharing traffic to the Windows File Server on LAN2 connects and browses, but after several minutes the connection encounters errors. LAN2 computers accessing remote shares on LAN1 also experience the same problem. On Mac's, the directory window closes and the mapped directory disappears. On Windows clients, during a file transfer, an error indicates the that location is no longer available.
With Windows clients this usually occurs with larger files, or when transferring entire directories. On Mac's, no transfer need to occur before, after several minutes, and sometimes much longer, the window browsing the shared directory will close and disappear. One must reconnect to the shared directory to re-establish the connection.
When documents have been opened and edited remotely, all modifications will have been lost prior to the most recent save, and the document must be reopened again.
Other considerations:
CPU usage is never really over 2%, and Table States usually stay below 200/10000. MBUF Usage = (router1 776 /1665 | router2 786 /1920). Memory Usage on both routers is approx 25%.Conclusions:
I'm looking for suggestions to likely problems, or software configuration changes I may want to adjust. Would changing the MTU values on the interfaces help at all? I'm not sure why the other protocols don't seem to suffer where as Windows File Sharing barely works.Are there any known incompatibilities or bugs with the hardware that I am using?
I would really appreciate some helpful insight. Is there any other information that I may provide that would help? If I can't find a solution, they are going to have me get rid of pfSense and go back to using either AdTran or Cisco routers =\ Everything seems to work great except for Windows File Sharing at the moment, but that is unfortunately most important to them.
.</t1></t1>
-
That might be broadcasting problems of NetBios. Can you try to access the shares with the ip directly instead of using computers name and see if the problem exists again?
If not there might be problems with path mtu discovery since file sharing might be sending packet with Dont fragmetn bit set and in pfSense you need to set some scrub rules to remove that flag, though not possible through the GUI afaik.