Weird issues when accessing CIFS over the WAN

[tomasz_pojda]

There are 2 locations, HQ and remote. CIFS has been installed to share files over the WAN. It does work really great locally (in the HQ), but when remote users trying to access over the WAN they face weird problems like: none connection at all, wery slow response time. Our 1st idea was to check network performance, but after several tries we found out that without MS ISA, over the same network it works well. WAN works on CISCO switch and routers. Below you will find a diagram.

To make this situation even more weird here is something what we observed:

When we connect to Netapp via 10.7.100.100 we don`t have any problem, but through 10.7.7.100 it doesnt work.

Due to the local policy we cant use working interface (yes, i know its stupid, but what can you do), besides I dont see the reason why

it should work via 1 interface, but not on 2nd one. Interfaces are physicial, not virtualized.

Question: Do you experience similar problems of ISA Server cooperating with NetApp? How to fix the problem? ISA itself have all necessary rules (port 445...),

but even fully opened generate the same errors. On the internet we found some similiar situations and some of them were caused by CISCO, but we think

in this very location its rather ISA.

[prakash_aviva]

Have you checked your WAN link from HQ to the remote site for the 2nd interface?

Also, check the etc/rc file for any route entry required for the 2nd interface.

[enrjfitz1]

Hi, can you confirm that CIFS works from a remote connection when the CIFS is provided by a fileserver eg at 10.7.7.50.

Start big and narrow it down I believe is the best approach.

Nice pic btw =D

[tomasz_pojda]

all traffic is routed through 1 gateway. first interface is crypted, 2nd not. we cant change the IPs. live systems, too many related applications to be reconfigured.

according to our observation network itself is fine. its rather about the firewall and maybe cryptography. most weird is that it doesnt work all the time, but almost

all the time, so it shouldnt be a network, but something a layer or two above, which interfers, but not totally stop the service.

usually after we manage to get a connection between storage and host (after 6-10 refreshes) connection is lost. so basically what user face on crypted interface is:

- long time for connection

- crappy connection if he is lucky enough to establish one

- connection lost after few refreshes

we dont get any error messages from ISA when scanning IP.

[enrjfitz1]

I have seen an issue similar to this several times when attempting to access the NetApp filer internally. It was caused by a time difference between the Domain Controller and the NetApp filer.

Can you confirm that there is no time difference between the NetApp filer, the ISA server and the DC (if ISA uses this)?

[tomasz_pojda]

yes, time is synchronised.

[tomasz_pojda]

MS ISA was guilty.

[saalekreis_admin]

Hi Tomasz,

what was the issue with the ISA Server? We have a similar problem, during a vpn connection to a netapp cifs share over wan (and ISA 2006).

Thanks in advance.

[sethm]

Hello,

We ran into something similar to this with another customer yesterday, and from what we can see in packet traces, etc., the ISA Server load-balancing mechanism was resulting in out-of-order packet delivery.  We worked-around the issue by disabling IP fastpath (options ip.fastpath).  Please note: fastpath gets blamed for all sorts of things that aren't it's fault - it works properly, and if the rest of the network is behaving properly, it is a useful tool.  That said, if you get into a situation where something sends from a MAC address, but wants to receive the reply on a different MAC address (which I would argue is promiscuous and inappropriate), disabling fastpath may help.

Cheers,

Seth