Frank,
I have a problem following the structure of your argument and I apologize if
my emails are misleading you.
I hope the confusion is mine only. Let me make sure I get on the same page
with you first.
My initial comment referred to automatic NAT, which is configured in the NAT
pane of the object's properties.
Yet you insist on manual NAT i.e. when you manually create your NAT
rulebase, which is fine, except that there
are some differences like the one I pointed out in my initial remarks.
Now, about NAT and routing (please excuse me if I repeat things you already
wrote, I'm doing it for the sake of consistency).
The are significant differences and in fact CheckPoint implements several
different functions.
1. Hide NAT. Without delving into the purpose and benefits of the hide NAT,
here is a simple communication path, inbound inspection only.
A packet leaves Client A (IP 10.10.10.10) destined for Server B (IP
15.15.15.15)with 11.11.11.11 NAT. It reaches the internal interface,
the firewall performs anti-spoofing check, matches the rule makes filtering
decision, passes to IP which makes routing decision,
then in our case shoots it down the stack to CheckPoint again, which now
matches against the NAT rules, and in our case invokes
the FWXT_HIDE function. FWXT_HIDE overwrites the source address in the
packet header to the Hide NAT address and puts it into the
appropriate NAT tables, passes it down and heats up the wire. Rule of thumb
one is in effect. See my earlier comments.
The reverse packet comes back and hits the external interface. Firewall-1
sees that it is, let's say, an ACK, matches it against the connection and
NAT tables, NATs the destination IP to 10.10.10.10, matches against the
rulebase, makes filtering decision,
and then passes it to IP for routing decision, IP driver sees that it is
destined for 10.10.10.10 which is in its routing
table to go out the internal interface, and then down to CP again which
invokes the NAT rulebase which does not contain a match,
shoots it down stream. Rule of thumb two is in effect.
2. Static source mode is very much the same. Except I don't think you can
reuse the NAT IP address.
3. Static destination is the one at hand. Let's say our server B wants to
initiate a connection with our Client A.
A packet leaves Server B and hits the firewall. The firewall matches against
the rules, which is why you want to have the rule
specify source IP 15.15.15.15 and destination IP 11.11.11.11. FW-1 approves
the connection and passes up to IP. IP sees that
the destination is 11.11.11.11 and the only match it finds is the default
route (in most cases the external interface). Sends it
down the stack to CP, which now matches the NAT rules and re-writes the
packet header so that the destination address is 10.10.10.10.
Send it down the stack, L2 drivers now know that it's supposed to go out the
external interface and your packet goes back out,
or wherever your default route is pointing, but in most cases out to no go.
Yet in your logs everything seems nice and peachy.
If the IP driver finds a match in the routing table for 11.11.11.11 out the
internal interface you are all set.
Reverse packet comes back from Client A. CP matches to the tables, NATs,
inspects etc. send it to IP which does not know about 15.15.15.15
but has a default route out the external interface etc. etc. etc. World
makes sense again.
4. With automatic NAT everything falls together nice and neat because the
firewall applies the object properties when it matches the rulebase i.e. it
would perform NAT there. See my earlier remarks regarding this.
If you have a lab environment or a firewall that performs complicated
address translation, you can snoop your interfaces and find out for
yourself.
* * *
That was a rather long email. Let me know if you have questions.
Cheers.
George
-----Original Message-----
From: Frank Knobbe [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 22, 2001 8:28 PM
To: 'Juppunov, George'; [EMAIL PROTECTED]
Subject: RE: [FW1] what occurs first NAT or RULEBASE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Juppunov, George [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 22, 2001 7:27 PM
>
> I think you mis-read my email. I was referring to automatic NAT,
> [...]
>
> The biggy is when you have a static destination NAT. Then you
> want to make
> sure you have a
> route to the external address out the interface where your NAT-ed
> host should be reached through.
>
> However when you use automatic static NAT, you don't need to
> put that route
> in. Although I'm not
> intimately acquainted with the specifics of CP's driver I
> presume the reason
> for the latter is
> that CP translates the address at the point of applying the
> security rules
> (i.e. not the NAT rules)
> because the info is already recorded in the object properties.
It doesn't matter if you configure an object with Static or Hide NAT.
That will only affect the creation of the translation table rules,
but it has no effect on NAT itself. The reason you don't need routes
for any outbound connection (from a static or hide NAT object), is
that the state table will assist in the correlation/translation of
the packets. Only unsolicited packets (read, not from an established
connection) you need the route to 'guide' the packet to the correct
interface.
Regards,
Frank
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8
Comment: PGP or S/MIME encrypted email preferred.
iQA/AwUBOzQMopytSsEygtEFEQKeEQCg363Al0DdG8rYHy3wPwBPkJfVbh4AoNRt
3vuMaah+GgRClFHzO/1lhBtl
=SIzW
-----END PGP SIGNATURE-----
_____________________________________________________________________
IMPORTANT NOTICES:
This message is intended only for the addressee. Please notify the
sender by e-mail if you are not the intended recipient. If you are not the
intended recipient, you may not copy, disclose, or distribute this message
or its contents to any other person and any such actions may be unlawful.
Banc of America Securities LLC("BAS") does not accept time
sensitive, action-oriented messages or transaction orders, including orders
to purchase or sell securities, via e-mail.
BAS reserves the right to monitor and review the content of all
messages sent to or from this e-mail address. Messages sent to or from this
e-mail address may be stored on the BAS e-mail system.
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
