[northlandboy]

Sorry if I wasn't clear enough, let's try again with some numbers punched in.

The key thing here is that the /24 network we're using for NAT doesn't physically exist anywhere - it's not going to be directly connected to the upstream router - it's not going to be configured on any device at all, it only exists virtually.

So, with some addresses, for the case where you would use proxy ARP:

* Assume our DMZ address range is 172.16.0.0/24. FW is .1, mail server is .2.
* Our public address range is 200.100.50.0/24. Upstream router is .1, FW is .2, and we're going to use 200.100.50.3 as the NAT for our mail server.
* For the sake of simplicity, we'll assume the upstream router has a default route to the Internet out its WAN link, and the only other network it knows about is the directly connected 200.100.50.0/24.
* To get this to work, we would add a proxy ARP on the firewall for 200.100.50.3, mapping to the firewall's MAC.

This way, when a packet from the Internet wants to get to your mail server (200.100.50.3), it gets routed to your upstream router, which knows that 200.100.50.0/24 is directly connected. Since it thinks it's connected, it sends out an ARP request for 200.100.50.3. The firewall responds, saying hey that IP address maps to this MAC address. The router then sets the destination MAC address on the frame to be the firewall, and puts the frame on the wire.

The firewall's NIC sees that frame, recognises the destination MAC, so it processes the packet. On the way up the stack, Check Point steps in, sees that it needs to NAT it, and it NATs 200.100.50.3 to 172.16.0.2, and forwards the frame.

All OK. Except we had to configure proxy ARP. And what happens if we've used up all of our /24 NAT range? What do we do then?

So here's an alternative design:
* Same DMZ range as before
* Same NAT range - 200.100.50.0/24 as before.
* This time though, we're going to use 192.168.1.0/30 as our network between the firewall and the upstream router. The upstream router will use 192.168.1.1, and the firewall 192.168.1.2.
* 200.100.50.0/24 is not configured on any device.
* Now we're going to add a route on our upstream router like this:
ip route 200.100.50.0 255.255.255.0 192.168.1.2
i.e we are telling the upstream router that to get to that public network, go via the firewall. Obviously you need to configure your upstream router to redistribute this route into BGP, or however you're letting the further upstream routers know where 200.100.50.0/24 is.
* Within Check Point, your NAT rule looks the same - NAT 200.100.50.3 to 172.16.0.2.

Now what happens when my server on the Internet wants to connect to your mail server? BGP routing tables will get it to your upstream router. Your upstream router knows that to get to that network, it goes via 192.168.1.2. So it sends out an ARP request for 192.168.1.2, the firewall responds, and the frame is put out on the wire.
Just like in the first case, the firewall will pick up the frame, since it has the firewall's destination MAC. It will look at it, realise it needs to NAT it, do that, and forward the packet to 172.16.0.2.

So we've achieved the same thing - we got the firewall to pick up a frame addressed to 200.100.50.3 off the wire, and NAT it. The difference is that we haven't had to do any proxy ARP configuration. And now think about what happens if we run out of space, and we get 200.100.51.0/24 assigned to us? We can just add a /24 route (more correctly, change the previous one to a /23) to the upstream router for that network. No further configuration required.

Note that you may wish to assign a public range to the network between your firewall and upstream router if you wish to do encryption. (Not so necessary at NGX though). You will also note that 200.100.50.1 and .2 are now available for use as NAT addresses, no longer being used for the router and firewall.

As a side note, in the first scenario, if you added a route like this to the upstream router:
ip route 200.100.50.3 255.255.255.255 200.100.50.2
that would override the connected route, and the router would forward those frames to the firewall's MAC. You wouldn't then need to configure a proxy ARP.

If you understand routing, and mac/IP translation, and layer 2 forwarding, it all comes together. You just need to think about what the point of proxy ARP is - it's purely to get those frames forwarded to the firewall. Once Check Point gets hold of them, it can deal with the NATting. Until you either route or proxy ARP for them though, the upstream router isn't going to forward them.

Am I making sense, or have I just made things worse?