Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 1809 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.
  • 0
    I've not seen that issue before.

    Best to run TCPDUMP on the bridge interface on the UTM, and look at it in WireShark.  If you have Standard or Premium Support, I recommend you start a support case if you're not too familiar with troubleshooting TCP/UDP sessions in detail.
  • 0
    Hi, also check the IPS and Firewall logs.

    Barry
  • 0 in reply to BarryG
    Hi, also check the IPS and Firewall logs.

    Barry


    Good point, I was assuming he had tried opening everything up and disabling IPS.  Also, check the Application Control logs... I've had that do some weird things sometimes.
  • 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?

    [:)]