Lets use the following assumption

{Internet} <200.200.200.1>..........<200.200.200.254>...........10.1.1.x
                                 :
                                 :
                             192.168.1.x

assume the following:
200.200.200.x is your class C address space (Internet space)
192.168.1.x is a DMZ
200.200.200.1 is the gateway to the internet (ie- live router ethernet port)
200.200.200.254 is the external interface for your firewall

Lets suppose internal hosts need to get out. (10.1.1.x hosts)

They use the firewall as a gateway, the firewall inspects, re-arranges, and
re-assembles and uses it's own interface as the new "source" address (and
assigns a port mapping to the internal host)
The packet goes through the router, and follows the path to the host
(somewhere on the internet)
When the packet finally gets back to the internet router, the router needs
to know where to send the packet to (ie a layer 2 address)

The router either looks in it's arp table, or does a rarp on 200.200.200.254
(the new destination address) and the firewall responds and says (give it to
me)

Lets suppose you are doing NAT for host 200.200.200.2, which NATs to
192.168.1.2

If someone initiates a connection for the host at 200.200.200.2, how does
the router know where to send it? When the router does a rarp on
200.200.200.2, nothing will respond. The firewall has to be "told" to
respond. Simply setting up a host and NAT rule does not cut it!

There are a few ways to handle it. Either you can put a IP route statement
on the router, sending all traffic destined for 200.200.200.2 to
200.200.200.254, and the firewall will know what to do with the packet. 

-OR-

you can also have the firewall PROXY ARP, which basically tricks the router
(or upstream gateway) into thinking that the 200.200.200.2 device is
actually there. 

Some routers have handled this by adding a blanket class C network static
route directly to the firewall.

Unix versions perform this function better than NT. On Unix, it's a simple
ARP pub command, on NT you have to add a file to the state directory that
basically has the address you wan to proxy for, and the MAC address of the
EXTERNAL nic, facing the router.

Sorry if I bored those that know this, but this is where many NT users get
lost....

Thomas




-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 16, 2000 11:04 AM
To: [EMAIL PROTECTED]
Subject: RE: [FW1] Routing before FW-1 Installation



Hi Thomas

What's the siginificance of the proxy arp stuff - I thought that the other
steps on their own would be enough ?

Tim Higgins



 

                    [EMAIL PROTECTED]

                    Sent by:                                    To:
[EMAIL PROTECTED]                                    
                    [EMAIL PROTECTED]        cc:
[EMAIL PROTECTED]                          
                    kpoint.com                                  Subject:
RE: [FW1] Routing before FW-1 Installation                   
 

 

                    16/06/00 13:49

 

 






hmmm  let me try to decipher.
Everyone can go out on the 10.10.10.x network to the internet, no
restrictions.
You  have setup a web server and want to provide inbound http access to
it.

A few  facts:
* Hide  mode NAT (I assume what you are using for outbound connectivity)
does not allow  for reverse connections (initiated by the outside)
* You  will have to use static NAT for access to your internal http host.

do the  following:
1)  Create a host (workstation) on the fw management server, make sure it
is set as  static NAT, with a valid external address
2) Use  the host in a rule, to allow access to it- ie  ANY   WWW_SERVER
HTTP  ALLOW
2) Let  the firewall proxy arp for this device, either via local.arp, or
static route on  downstrean router
3) Put  a static route on your firewall, to let the firewall know which
internal host to  send the packet to- ie
route  add -p 200.200.200.200 10.10.10.10


Your  last question is answered by the above statements, you **hopefully**
will only  be using three addresses of your external class C (254 possible
addresses) - I  am assuming the most basic setup!

1)  Router/Gateway Nic IP address
2)  Firewall External NIC IP address
3) IP  Address for the Internal host (external)

Thomas
-----Original Message-----
From: Flavio Muscetra  [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 16, 2000  8:59 AM
To:  [EMAIL PROTECTED]
Subject: [FW1] Routing  before FW-1 Installation


I have a NT box with FW-1 installed.

Actually i have 3 ethernet adapters, but it seems  to exist some problems.
The third ethernet card was added after the FW-1  installation.

The actual FW-1 configuration allows PCs behind  the FW on the the net
10.10.10.x to connect to the Internet without  restrictions. When i tried
to allow HTTP connections from Internet to one PC  on the 10.10.10.x net it
doesn't work. I used as public IP the ethernet public  adapter IP.
I think the problem is in the NT routing  configuration and not in FW-1
configuration.

I'm also lost as to why you have two different NICs on the same  network.
You may want to move one of them to a DMZ-  ie-
192.168.x.x or  172.16.x.x

I try to describe the system:

ethernet1 (public interface 199.199.199.111) net  199.199.199.x (C-class)
ethernet2 (private interface 10.10.10.1)   net 10.10.10.x (C-class)
ethernet3 (private interface with the same ip of  the public net) net
199.199.199.x (C-class)

Which is the correct NT-routing table between  these ethernet adapters?
Is it possible to use the same C-Class for the  Internet and the third
private ethernet adapter (not using the same  IPs)?

Any help is welcome!






#**********************************************************************
This message is intended solely for the use of the individual
or organisation to whom it is addressed. It may contain
privileged or confidential information.  If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you should not use,
copy, alter, or disclose the contents of this message.  All
information or opinions expressed in this message and/or
any attachments are those of the author and are not
necessarily those of Hughes Network Systems Limited,
including its European subsidiaries and affiliates. Hughes
Network Systems Limited, including its European
subsidiaries and affiliates accepts no responsibility for loss
or damage arising from its use, including damage from virus.
#**********************************************************************


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================

Reply via email to