Micheal,
If you get an answer to this one drop me a note.
You are the second person I've seen ask this question, so I thought I
should respond even though I don't have an answer for you. To my knowledge
FW-1 DOES NOT NAT PORTS, If you are doing NAT that's fine and everything
should work well.
I've taken both the CCSA and CCSE courses and they don't mention NATing
ports...
I'm curious as to why you mentioned Apple.Com specifically? I've noticed
that apple has been having ALLOT of problems lately, could be your problem
is not internal and is actually Apple's problem... Or is this happening
with other sites as well?
-----Original Message-----
From: Espinola, Micheal [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 07, 1999 1:17 PM
To: '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject: Firewall-1 NAT/DNS issue
Hi everyone,
This is my first question posting to this list, so please be easy on my lack
of firewall knowledge. In the intro to my problem, I have tried to explain
what I *think* is going on in the process. If you see anything wrong with
my interpretation, please feel free to correct me - the more the better.
Firewall-1 NAT issue:
Firewall-1 (FW-1), like many other enterprise-level firewall products has a
security-related functionality called Network Address Translation (NAT).
NAT in its purest definition is a process in which IP addresses are hidden
(by the firewall) between one side of the firewall (or possibly both) from
the other.
Like my company, many organizations depend heavily on NAT in order to
protect internal networked systems from outside access by preventing that
outside source from ever learning the internal system's IP address.
This feature of the NAT process is referred to as "Hiding". FW-1 takes this
an additionally-secure step further by also performing the NAT process on
the port that the Internet communication is taking place on. For example,
HTTP (World Wide Web) communications typically take place on port 80.
Because many important Internet-related functions take place on ports that
are within the 1-1023 range, FW-1's NAT translates communications taking
place within this port range, and changes them to a different port number
within the range of 600-1023. This port range is non-modifiable.
This change of standard port-related communications to non-standard port
numbers can "break" the working functionality of an Internet
process/function because the receiving system may only allow certain
communications to occur only on a certain port. Case in point:
Domain Name Service (DNS) is an Internet-related service that provides the
ability to "look-up" an Internet Domain Name address (i.e.
www.microsoft.com) and translate it into an IP address (i.e. 207.46.131.13).
All Internet communications are actually transacted by IP address only, so
DNS is essential to Internet communications.
This can be put in layman's terms by comparing the process to a telephone
call. For instance, you may want to make a telephone call to " John Smith".
You cannot pick-up the telephone and place a call to "John Smith's" name.
You need to call an information service (i.e. 411 is an information service
in the US), to find out what "John Smith's" phone number is (i.e. 555-1212).
Because of FW-1's NAT "Hiding", DNS communication to certain Internet sites
(i.e. APPLE.COM) from my company's internal network is broken. A layman's
overview of the DNS process failure is as follows:
1. Internal user wishes to connect to www.apple.com.
2. Internal user's computer does not know www.apple.com's IP address.
3. Internal user's computer make a DNS "Look-up" request to a
pre-configured internal DNS server.
4. Internal DNS server does not have www.apple.com in its local database.
5. Internal DNS server makes a "look-up" request to a Top-Level Internet
DNS server. This is commonly referred to as "Forwarding".
6. Internal DNS server is provided with an Apple DNS server's IP address,
as provided by the InterNic.
7. Internal DNS server contacts an Apple DNS server and requests a
"Look-up" translation of www.apple.com.
8. Internal DNS server's request is dropped (or possibly denied) because it
has been translated to a non-standard port (DNS is port 53, but has been
translated to a random port between 600-1023).
Note: The DNS communication is NOT broken if the Internal user is using an
external DNS server for DNS requests (even from behind the firewall). The
DNS "Look-up / Forwarding" failure is only between the Internal DNS server
and the Apple DNS server.
Possible solutions to the problem?:
1. Can CheckPoint (the maker of FW-1) fix this problem? Have they already
in a product update?
2. Can Internal DNS servers perform "Look-up / Forwarding" through a Static
NAT for all DNS requests or per DNS server?|
-
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
