File sharing problems across PIX 502 firewalls

I have a LAN segment (10.10.1.0) that connects to the Internet through a PIX 501 firewall (PIX1), fairly typical settings using a Pooled NAT address (67.135.65.90). In a separate stack, I have a bunch of web servers (192.168.1.0) that connect to the Internet through another PIX

501 firewall (PIX2) using static NAT for each device (67.135.65.66 - 80).

I want to be able to access fileshares and other services running on the web server stack from my LAN, so I ALLOWed all incoming traffic on PIX2 from address 67.153.65.90 for TCP and UDP on all ports.

Most of the time, I can see the web server fileshares via their UNC paths. When I do this, I am prompted for credentials on the web server machine (so this is not using Windows Integrated Authentication in any way). Occasionally, I get "network path not found", but only rarely. I can generally interact with most file types (open, save, rename, delete, etc). But I have two recurring problems:

  1. When copying large numbers of files or large files to/from the fileshares, 50% of the time (approx), I get a message partway through the process that the "Network name is no longer available". If I keep trying, the procedure will eventually work.

  1. 99% of the time, I can not open an ArcGIS project file (.mxd) from the file share. ArcGIS complains with a variety of different error messages, but almost always fails. I do not think this is an ArcGIS bug, but rather something related to the issues in 1 above.

Has anyone succesfully set up file sharing over the web where your origin is a NATted LAN and your destination is another NATted LAN? The connection path is direct (the two PIXes plug into a switch that then plugs into the WAN router), so I don't think it's a routing or a latency issue. My other thought is that it might be related to the fact that the external addresses of each PIX (a single pooled address on PIX1 and multiple static NAT addresses on PIX2) are in the same subnet.

Thanks for any help,

John

Reply to
JohnH
Loading thread data ...

...

Yes, with an IPsec tunnel. SMB/CIFS file sharing through a firewall is problematic at best even when using all of Microsoft's available docs and kb articles. If you've never set up IPsec before, the PDM's VPN wizard is quite helpful, even in the 6.X(X) releases.

See the 'Site to Site VPN with PIX' section of this page for some helpful command line examples:

formatting link

-Gary

Reply to
Gary

formatting link

I set up the point-to-point VPN, it was very easy. It also resolved all of the file sharing problems I was having. However, 2 issues arose. One, I realized that the VPN has no protection for the LAN from the web stack. Also, the speed is abysmal. I'm just using simple DES encryption, but my transfer speed (e.g., on my tape backup process) dropped from 300MB/s to 60MB/s or less.

So, back to the original idea, is it possible to reliably file share across two NATTed PIXes?

If not, can I apply firewall-like access rules to the VPN traffic? If that is possible, what is a good hardware VPN solution that will get my transfer speeds back up to some reasonable level?

Thanks again for any info/help!

John H.

Reply to
JohnH

formatting link
>

Your performance is not going to change much, as the VPN doesn't cost that much.

Your upstream and downstream are going to be the limiting factor.

If you want to bypass the firewall, then make sure that you create at least an IPIP rule so that only the two IP's can share between them.

As long as you make an IPIP (public IP's) rule and then NAT the MS File sharing ports on each side, you should be able to connect.

60MB/s is good over the Internet.
Reply to
Leythos

Um, what are you using for your connection between the two systems? Is that 60 mega Bytes per second or 60 mega bites per second? Even if it is the latter, that is better than an OC-1 connection, which is 45 mb/s (mega bits per second). I would be very happy with better than an OC-1 connection to my web server.

File sharing, as in SMB / CIFS file sharing is problematic at best when you cross subnets. Even bridging across the VPN is problematic as you have to watch your broadcasts.

To help your speed, first and foremost use WINS, or add entries for static IPs in your LMHosts file. I don't care if you are talking about 2k or better, which will use DNS, still use WINS. Do not use UNCs to access your data, but rather a mapped drive.

Depending on what your connection is, I'd say that you do have a good reasonable level. How were you getting the 300 MB/s? What sort of connection were you using?

No problem.

Grant. . . .

Reply to
Taylor, Grant

No. Why should it?

Of course a bridge has to replicate broadcasts. But: what did you want to tell us?

Or just configure ActiveDirectory correctly.

Why?

Yours, VB.

Reply to
Volker Birk

SMB / CIFS is (or has been in the past) notoriously a broadcast to locate based networking protocol. Seeing as how broadcasts do not traverse subnets with out help, location of systems can be problematic. This is why WINS / LMHosts and / or DNS need to be set up for the location of systems. If you know the IP of the system on another subnet that you are trying to connect to you can do so much more successfully than if you are trying to locate the system by a name.

Routing, which is usually what is used in VPNs, will hinder broadcasting for hosts which are in another subnet. However you just said bridging, which would most likely put the systems on either side of the VPN in the same subnet.

*nod* AD uses a combination of (primarily) DNS and LDAP to locate systems. To my knowledge, LDAP says the who, and DNS says the where. However LDAP can augment DNS at times. Of course there is also DNS that uses the AD LDAP back end to store it's zones...

It has been my experience that when you use UNCs to access systems, especially across subnets, that the client computer will have to re-locate the server that is being referenced for each and every connection. Where as a mapped drive will do the lookup one time and establish a session between the client and server. This is akin to connecting to the server and asking for a file and then disconnecting verses connecting to the server and staying connected all the time. Granted, 2k / XP / 2k3 is better about this than older network stacks, but they still suffer to some extent. I have found consistently better performance using mapped drives than using UNCs.

Grant. . . .

Reply to
Taylor, Grant

SMB? Yes. CIFS? No.

Yours, VB.

Reply to
Volker Birk

They are connected across a 100MB hub. The hub connects them both directly to the Internet, but the VPN traffic doesn't go out.

These speed issues generally relate to the delay in browsing the Windows network or establishing a connection to a shared resource. I'm not having a problem there. The problem is in raw transfer speed.

With the firewall setup, aside from the errors I get intermittently, I can copy a large file (say 7GB) to a fileshare in several minutes. When I use the VPN setup, it's very reliable but the transfer takes over an hour.

- John H

Reply to
JohnH

I'll concede that.

Grant. . . .

Reply to
Taylor, Grant

Ah... Ok.

Ok.

Have you considered changing the VPN from the format that it is presently to something else. What are you presently using for your VPN? Are you using the built in VPN server and client in Windows? Are you doing an IPSec connection?

After rereading the original post, do you really need the VPN, or do you need to resolve your "... file sharing problems ..."? What problems were you having? What is your network config? I suspect this is more reminiscent of the problems that Volker Birk and I were discussing.

Grant. . . .

Reply to
Taylor, Grant

I just need to resolve the file sharing issues. The VPN was software on the PIX devices (FWIW). The network config in a nutshell is:

LAN -> PIX01 -> PIX02 -> Server

The server is on 192.168.200.0/24, the LAN is 10.10.50.0/24 and the outside interface of each PIX has an address on 67.135.65.64/27.

PIX01 is closed to all incoming traffic, open to all outgoing traffic. PIX02 is open to all incoming traffic from PIX01, selectively open to incoming traffic from other sources, and open to all outgoing traffic.

PIX01 translates the LAN addresses to a single PAT address. PIX02 has a static NAT mapping for the server.

The "issues" were intermittent and included errors while trying to copy files between the LAN and the server (e.g., "Network share is no longer available"). Also, ArcMap running on a LAN machine reported various errors while trying to open files on the server ("Unable to open file..." and other more mysterious errors).

Thanks for using up precious brain cycles on this...

- John H.

Reply to
JohnH

This all seems simple enough.

I'm not a Cisco guy, so I can't say for sure, but... I believe I have run in to Cisco gear that was set up similar to what you are doing. Each end router (not a PIX) was configured with ""Helper addresses for specific systems on the other networks. I.e. PIX01 would have a helper address for a server on PIX02's network. Vice versa, PIX02 would have a helper address for a system on PIX01's network. I believe the idea was to make hosts appear as if they were on the client's network. This way broadcasts would go to a local subnet address and then be redirected over to the real server on it's network. I don't know the raw details, but I believe that is what I was told.

Not to rehash the same details, but did you try adding entries in to respective LMHosts files to tell hosts where other hosts were? Your issues do sound like they are related to network stacks not being able to find target hosts with in time and thus the connections were failed.

Grant. . . .

Reply to
Taylor, Grant

New evidence - when I use a static NAT address on PIX01 instead of the pooled address, the problems appear to go away. I haven't done extensive testing but I was sitting at one of the LAN machines that just refused to copy a folder from one of the servers, saying "Network name no longer exists" every time I tried. So I changed the PIX setups on the spot, and the folder copied just fine.

Seems like an incompatibility with the use of a pooled address for all the LAN machines?

- John H.

Reply to
JohnH

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.