Routing for a Virtual Server in Checkpoint

Will wrote: : With at least older versions of Checkpoint, you have to establish manual : routes in the OS to move packets that require NAT to the correct interface. : For a simple mapping of one external IP to one internal IP, this is trivial : and works fine. But how are you supposed to do the routing for the case of : a virtual server, where one external IP may map each of three ports to three : separate destination IPs on three separate DMZ networks? It's not clear : for such a case how static routing rules would apply.

Will, I don't know what version you're using, but newer versions (NG and up) understands and does this automaticly. It's called automatic ARP.

In older versions (->4.1) you had to define this arping manually. On windows you could specify this in a local.arp file, while on other systems you had to use the os specific arp commands and put them i a startup script, possibly in the same script that starts the firewall daemon. With newer versions of Checkpoint you can also use "client side natting" to avoid the need for such manual routing.

Lars

You still need it on some NGX platforms when working with manual nat rules & VIPs on different subnets.

greg

Hello there,

In fact it depends if you're doing prenat or postnat. One of them doesn't require routes at all, but beware ... you may need to review your entire rulebase (prenat is doing the NAT or de-NAT on the input interface ...postnat on the output interface). That's what they call "client side natting" or "server side natting".

Also, don't forget that manual natting exits at the first match, when automatic nat can do two rules (source and destination).

The routes you have to insert in the OS are only to determine "to which interface should this packet be sent". Quite logical if you think that the address in question may be connected to the outside interface or even to no interface (case of a "pure virtual network").

"Automatic ARP" is there only to ensure that the NAT address can be resolved to a physical (ie ethernet) address. Without that, you'll have to insert proxy ("permanent public" in term of BSD) arp for each nat (static or hide) you can have ... or insert host routes in your outside router.

The best thing to do is to play a bit with prenat, postnat and stuff like that. Only with that you can decide if you go for it or not.

Regards, Jean-Francois

"Greg Hennessy" a écrit dans le message de news: snipped-for-privacy@4ax.com...

Don't confuse the arp issue with NAT. At least on the older Checkpoint product, they are completely separate. You have to define static routes on the pre-NAT addresses in order to have them routed to the correct destination interface.

If you automate the arp, and you want to use NAT after routing, wouldn't you still need to create static routes to get to the correct destination interface?

My case is a little too complex for a simple static route. I want:

192.168.10.13:80 -> 172.16.16.14:8080 192.168.10.13:53-> 172.16.13.13:53 172.16.16 and 172.16.13 are separate class C networks on separate DMZ interfaces of the firewall. I can't just route all packets coming to 19.168.10.13 to one of these two destinations arbitrarily.

What's the general opinion on which form of NAT is more secure?

Right, but my question (still unanswered) is how do I do those routes when I have one external IP, with three target ports that I want to map to three different target computers on three different DMZ networks? I can't just route one static IP to one static IP, and I can't route the one IP to one DMZ network. That will deliver the packet to the incorrect DMZ interface for two of the three target hosts.

I'm not having any problems with the arp part of this.

Well ...

Good question.

Virtual server has two modes : HTTP redirect and NAT.

In HTTP redirect, basically, you just send a "move to:" directive to the client, which in turn makes a new connection.

In the NAT scenario, I guess that one of the mode (pre or post nat) may work, but without certainty. I've never changed the NAT mode of our firewall from the "heroic days" when we were used to 4.1 ...

I remember that the justification for this new mode was that "it suppresses the need for explicit routes". So, i guess it's something I have to try. I can't promise I'll do it for the end of september, but I think I may have enough time during october. If it can wait ...

Regards, Jean-François Gobin

"Will" a écrit dans le message de news:

5e2dncTbXpPc3pPYnZ2dnUVZ snipped-for-privacy@giganews.com...