help - PIX translation and ports question

Hi,

My company just got a PIX 506E and unfortunately I am not very experienced with it, and am having some big problems. I have 2 PIX books and have looked online but am for some reason having big problems with doing things that should be easy. I dont know if this is because I am using PDM and not the CLI or what...but I desperately need help.

Here is what I need to do:

The PIX sits in front of our LAN....nothing else is behind it. Our web and mailserver are at our ISP.

We are switching to Exchange, also being hosted at our ISP.

When I first set up the PIX last month, I used the PDM wizard, and it created a single PAT translation rule:

global (outside) 1 interface nat (inside) 1 0.0.0.0 0.0.0.0 0 0

I am embarassed for how newbie these upcoming questions are going to be:

interfaces:

PIX outside interface = 164.60.128.2 PIX inside interface = 192.168.1.1

Exchange server = 64.74.74.31

We will be having 5 exchange mailboxes.

What exactly do I have to do to create an ACL that will allow this traffic {TCP 135 and 139 and UDP 137 and 138 (and whatever other ports I need to open)} from 64.74.74.31 into my network?

Is PAT screwing me up?

Could someone please help me here...opening up ports should not be so hard.....this is really frustrating me.

Pix 6.3(5) PDM 3.0(4)

Thanks in advance for your help

Reply to
Mike_B
Loading thread data ...

I notice that you list the NETBIOS ports but do not list the LDAP ports. That suggests that you will be using the older Exchange 2000 rather than the newer Exchange 2003. I never really had a chance to test out the flows for a properly configured remote Exchange 2003 server, but I have had... "interesting times"... with PIX and Exchange 2000.

If you are a Microsoft devotee, then YES, whatever does not work with a Microsoft product is Broken. But for the rest of the world, accustomed to standards and objective security, the answer would be NO, that it is Exchange 2000 which is screwed up.

In my experience (and I pushed at the matter), unless you have really good Exchange server administrators that know just how to tweak the product, what you need to do to access a remote Exchange 2000 server is as follows:

- Use static public IPs for all of your hosts that will need access

- Use a WINS server that both sides will have access to (e.g., the Exchange server itself)

- configure your PIX to allow ALL traffic from the Exchange server, and ALL traffic to the Exchange server. (You might be able to get away with blocking -some- of ports below 1024 though.)

Unless the Exchange server is carefully nailed down, attempting to restrict the connection to only a "sane" subset of the ports is doomed to failure. If you restrict the ports sanely, most of the time you won't even be able to figure out -what- failed. but you will be able to see from the detailed PIX logs that -something- was blocked.

Exchange 2000 Server *will* attempt to connect back to arbitrary ports on your client. And it will keep trying to attempt to connect to that arbitrary port about every 15 minutes for about 10 days solid. If you trace back through the logs, you will find that that arbitrary port was one that the client once used to talk to the server... anywhere from 10 minutes to 2 months earlier. And you will find that some of those previous conversations were -outgoing- TCP connections that originally lasted perhaps 2 seconds and were properly closed down at the time... but weeks later the server will expect the client to be reachable

-incoming- at that same IP + port. Ignorning the PAT and stateful firewall issues that raises, what sane programmer would expect a Windows PC client to stay up for more than a day at a time? Even if Windows hasn't crashed by itself and even if the anti-virus program doesn't require a reboot in order to try to catch the Malware Of The Hour, one should expect that the user might have turned off the computer overnight...

Then there are the strange interactions with RPC translations and adaptive security...

Do not rely upon Microsoft's list of ports you need to open. In practice, there are -many- more ports you will need. ("Oh, that undocumented port you found isn't used specially by Exchange itself, it is used by the infrastructure layers that Exchange is built on!")

Now, there are some people who disagree with me and believe the Exchange is perfectly secureable. In particular, Leythos over in the firewalls newsgroup claims that his company has implemented such configurations often. As best I can tell, though, in each case his company had the freedom to configure the Exchange server.

Reply to
Walter Roberson

Hi Walter,

Thank you very much for your help.

Do you have any experience with RPC over HTTP? I do not know if my ISP has that set up - but from what I have read, RPC over HTTP would save me from all of the stuff that you described.

Reply to
Mike_B

Sorry, No.

I would tend to doubt that RPC over HTTP would solve the issues I encountered. Exchange 2000 attempts callbacks to ports which were logically closed long before, and which could well have been recycled for other uses in the meanwhile.

What you need to fix the problems I saw would be a Layer 2 Transparent VPN, such as is possible with the PIX 515/515E, PIX 525, PIX 535, and Cisco ASA 5500 series, when running the 7.x code revision. That would, though, require that your LAN be an extension of the ISP's LAN.

Reply to
Walter Roberson

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.