WILL PAY. Need help to setup VPN between a PIX 506 and a Checkpoint 4.1 Firewall
We switched from DSL to COMCAST and now with the NetBIOS ports all closed, we can't get our Outlook Client (in corporate mode) connected to our Exchange Server across the Internet. We need a site to site VPN Tunnel to be set up. Both sites are using NATTING.
Name a fair price and I will describe the network in details and reset password for you to come in. Payment will be via paypal.
Please IM to beyondautomation or email to snipped-for-privacy@yahoo.com.
NETBIOS and remote Exchange server implies Exchange 2000.
That being the case, you cannot easily do what you want with a PIX 506 -- at least not without locking down the Exchange server far more tightly than the corporate Exchange people at my work were ever able to do.
Leythos has indicated that his company has the expertise to do that kind of lockdown, but I gather that his company would require full access to the Exchange server for that, and I'm not sure if they have PIX or Checkpoint expertise.
Exchange 2000 that is not expertly locked down makes some rather bad assumptions about the persistance of ports long long after any sane application would have assumed that the ports might be closed.
The behaviour includes:
Client source port P opens TCP to Exchange -server-; data is transfered; a normal cleardown of the connection occurs within seconds; minutes to weeks later (10 days seen several times, 14+ days a few times), the -server- attempts to open a connection -to- client port P (note difference in direction from the original transaction); if P is not reachable, the server will retry for days and days and days...
Unless you can find the arcane Exchange server lockdowns, the only way to account for these issues on the firewalls is to allow *all* TCP and UDP high ports from the server(s) to the clients.
You will, of course, require a WINS server to allow the hosts to locate each other. You must use untranslated IP addresses for the tunnel, and the WINS server must only ever see the internal IP addresses, so the WINS server must also be reached locally or through an untranslated VPN tunnel. If the WINS server is reached through a NAT'd connection, then the WINS server will end up learning both the public and private IPs for hosts, and it is pretty much unpredictable which of the IPs the Exchange server will attempt to use for any given transaction... one thing you -can- predict is that if the WINS server ever learns the public IP then it will at some point attempt to contact the public IP even though the only way to make the connection is to the private IP via the VPN tunnel.
The WINS vs NAT situation is worse than it sounds: if there is another location that uses the WINS server, and your local office communicates through NAT to the PDC or BDC of that other location (e.g., as part of distributed NT authentication), then the other office will learn the NAT'd IP and will pass it along through -its- WINS connection to the WINS at the server location, and the server will promptly randomly try to connect to that NAT'd IP. PDCs and WINS gossip and Exchange believes the hearsay, no matter how many times removed. And it is amazing how many PDCs/BDCs will elect themselves and will try to talk to you -- at least one per remote NETBIOS domain, and half a dozen per remote NETBIOS domain was often observed in practice.
If you are using NT authentication, then the set of ports you need will be much larger than Microsoft documents. If you are using calendaring or other such features, ditto. If the Exchange server is internally distributed into several computers (especially if the message store is not at the main Exchange server address), then ditto.
If allowed to (i.e., if you are not a serious Exchange configuration guru) random systems at other branches *will* attempt to contact your local clients. [We never did manage to figure out what they wanted to say...]
In short, to get it all working properly, you just about need to let all traffic through between all server and client computers, and between all client computers at your branch and all server and client computers at all the other branches.
You can be somewhat more restrictive if you don't mind if there are occasional inexplicable connection attempts in the firewall logs, and occasional random glitches in the workings of Exchange 2000. Very few of the random glitches will correlate to the inexplicable connection attempts, so my conclusion has always been that probably no matter -what- you do, Exchange 2000 will have random problems that are untraceable (except perhaps by true Exchange experts). When set against the random cruft of Exchange 2000, you might find that -in practice- there is no point in trying to get the firewall details "all working properly".
If you are okay with the possibility that when your Exchange 2000 server gets cracked, that your clients can be attacked by exploiting the trust relationship [as actually happened to 3 of our departments], and just naturally expect MS software to be buggy and take that into stride, then you might be happy enough with a simple non-translated VPN tunnel.
Sorry for not being very specific. It is Exchange 5.5. Security is not a major major concern (as the PIX restricts where traffic comes from). Speed and equipment are. Remote PCs running Outlook are not even authenicated by the domain where the Exchange 5.5 is. Remote PCs have to type in their passwords every time.
With DSL, everyth> > >Need help to setup VPN between a PIX 506 and a Checkpoint 4.1
Well, is there something wrong with contacting either one of the vendors? Maybe, either one of them can give you a lead to an expert that can help you.
Wow man, you were running netbios across the Internet? Highly insecure...
A garden variety VPN tunnel will work fine for OL connecting to EX55. It will need to pass UDP as well as TCP if you want to recieve new mail notifications.
Setting a tunnel up between a PIX and a Checkpoint shouldn't be all that tough, have you tried yet? Just don't NAT into the tunnel, the actual untranslated private IP's of the remote network willl appear on the local network and vice versa. At the remote side, give them the local WINS server addresses (ie across the vpn) so that they can resole all the local names, and it should all work fine.
Yeap, that will do except my PIX is running 6.34. I was still hoping to
Please quote context. Please see here for information on how to do so from Google Groups:
formatting link
I have reviewed the example referenced, and there is very little there which is outdated by PIX 6.3(4):
- remove the line, no sysopt route dnat because dnat was dropped and so there is no need to disable it
- the first of the "timeout" commands shown is garbled with some console output. Some of the minor details of the "timeout" command have changed, but if you just don't leave that part out then the default values are likely fine.
Also,
- remove the failover commands: failover is not supported on the PIX 506
- remove the line, access-list 115 deny ip 192.168.1.0 255.255.255.0 any because it is redundant (access-lists end in default deny)
- consider updating the transform set to 3DES or AES
- consider updating the isakmp policy to include 3DES or AES
- consider being more restrictive on the nat (inside) 1 statement. When 0.0.0.0 0.0.0.0 is used, if some inside host forges random IPs as the source for packets, the PIX would let the packets out (replies are unlikely to get back, but in the meanwhile state is used up... and single packets are sometimes enough to crack or DoS remote systems.) If you instead use the inside IP range and netmask, then the forged packets would at least have to have internal IPs as their source in order to be allowed out.
I can probably help, but it would take you to get ViPNet VPN
formatting link
That should work fine over PIX and ChaechPoint and provide NetBIOS connectivity, and Outlook. mail me if you are interested snipped-for-privacy@infotecs.biz
No professional is going to do take this project on. In addition to Pix being way old, Check Point 4.1 (before it was renamed to Check Point 2000 before the turn of the century) is unsupported. It's at least three major versions out of date (NG, NG AI and NGX) and dozens of service packs out of date.
It's time to spend some money on getting this stuff updated, dude. Your looking at some serious liability if customer data gets compromised in any manner. You cannot protect against 2006 risks with 1999 tools.
My company may be able to help you. Please let me know if you'd like to have a quick chat so that I can assess your situation. We are a Check Point partner, as well as a Cisco and Juniper partner with extensive expertise and engineering resources. In short, we do this all the time. I would recommend that you upgrade from CP 4.1 to NG or NGX, but we can talk about that.
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.