Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 1808 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro Bridge kills Windows Share

AdrienBelcourt
Hi All,

Have an interesting one.  Suggests Astaro Bridge kills Windows share protocol. 

If we plug a (manually configured) laptop directly into the MPLS WAN router, then we can open remote shares, join domains, etc.   No problems.  Fast response.  All nice.  

When we just put an Astaro bridge between the laptop and the WAN router - we cannot open the same remote shares.  Can see the traffic being passed, NetBios, 445/SMB, etc.   However, there must be traffic being silent-killed - and cannot tell what, short of using Wireshark both sides of the bridge to find out what is dropped. 

All the normal stuff works just fine across the bridge.  We can still join the domain.  RDP, FTP, etc.  Just windows shares is killed.  We are using Win Server 2003.  The Windows diagnostic is as useful as a chocolate teapot.  

Anyone any thoughts, please?    

My reading suggests that it is NetBios broadcast traffic that is likely being dropped.   The standard workaround for that is to enable, and use WINS server.   However, WINS server is deprecated and will stop being used by uSoft.  Also WINS is not currently needed to be used anywhere else in their 5 site network.  So is tough to argue that for this one just for Astaro .....   Customer is sure that Cisco would do this just fine.  It seems likely to me that a Cisco bridge would have less impact than the Astaro one.  But is that right? 

Thanks in advance for any thoughts or comments.

All the best,

Adrien.


This thread was automatically locked due to age.
Parents
  • 0
    Bruce and Barry,

    You are both Gentlemen.   Was so close to the problem could not see or think properly.  Switching off IDS and Application control brought things back.   Switching things back on did not immediately stop the File Share traffic.   This was because of the high level of Microsoft caching, I think.   Dump connection, try to connect when off air, then try to connect when back network connected was the only way to get a true result.  

    Bottom line - and I hate admitting this - application control was killing the traffic because CIFS had been included in a "no P2P" application control rule.  

    Of note, the context sensitive help suggests that network in an Application rule is for both source and destination hosts/nets.   But extensive testing - and the label in the displayed rule - suggests it is only source networks/hosts in that field. 

    Other than that - All good.  All tested.   All working.   

    Thanks again & have a good weekend.

    Adrien.
  • 0 in reply to AdrienBelcourt
    I guess Barry and I get to split the points on this one, ehh?

    [:)]
Reply Children
No Data