Originally Posted by northlandboy Some random thoughts on why I prefer manual NAT, partly in answer to other points, partly just my ramblings, in no particular order: * Automatic Proxy ARP - you may have had some success with it being configured automatically, but in my experience it causing nothing but problems. E.g. if you have a VRRP cluster, and hide NAT things behind the VRRP address. Reasonably common scenario, right? Except if you do it with a cluster, and automatically, the secondary node publishes a proxy ARP for the VRRP IP, causing all sorts of pain. ARP issues can take a little bit to track down sometimes too, particularly if an ARP entry is flapping. I've also seen it be unreliable too many times for my liking. "But it was working an hour ago..." The classic was where it would stop working, you would push policy, hey presto, it starts working again. Try explaining that to the people you've spent hours trying to convince that re-installing policy should not make any difference, since you're not changing policy. * Related to the above, you should not really be configuring your networks to require proxy ARP anymore. It's 2006, not 1996. Route it. You should not have to touch the modules to add a new NAT. Different rant though. * The time thing - it only takes me a couple of minutes to configure a manual NAT rule. An extra minute or two there, yes, but then I have an object I can filter on in Tracker, I can sort my object list to see what addresses I've got configured - rather than having to grep my objects_5_0.C to find which public addresses are used. In the NAT rulebase, I don't need to open an object, and change from the default screen, just to see what it's natted to - my tooltip tells me (aside - I love that feature!). An extra minute or two at setup is pretty much irrelevant to me, if it's going to save me a lot of time in future. * Almost foolproof - perhaps you are right, but I take a slightly different tack - I would rather have people that know what they're doing, and take care with their work, than someone who can work a drag and drool interface. * If you've got a medium network, with say a dozen clusters under that CMA, a few thousand objects, maybe several hundred NATs taking place on multiple firewalls, with some objects having two or more NATs on different enforcement modules - and this is a very realistic scenario, I've worked on multiple sites like this - then automatic NAT just doesn't cut it. Every automatic NAT shows up in every rulebase, regardless of whether that rulebase is installed on those modules or not. You just can't look through a NAT rulebase - but I guess perhaps you're not supposed to. * As soon as you have multiple layers of firewalls, you get in the situation of having to have manual NAT rules - even if it's sometimes to negate NAT in certain situations - e.g. a rule at the top to say "don't nat anything internal->internal". So you then end up with a mixture of automatic and manual NATs. It starts to become a bit of a mess, as you can only put manual nat rules above or below all the automatic nat rules - you don't have granular control. Is that a good policy to have both manual and automatic NAT rules? I would say not, in general. I think it's better to have a standard and stick to it. * If you've got a huge number of NAT entries, but the connections are only in one direction, you can configure the NAT rules in one direction only. This can vastly reduce the size of your rulebase (I've worked with policies with several hundred entries in the NAT table). * Granularity is probably the biggest one for me - sometimes I only want a NAT to apply for a specific source/destination pair. This is one of the things I love about Check Point NAT - this sort of thing is extremely difficult to do with Cisco. * If I configure two objects to automatically static nat to 1.2.3.4, do I get an error? I haven't actually installed a policy like this, but it definitely lets me define the objects, which is just wrong. At least if I try and do something similar with manual NAT, I'll get a warning when I create a new object with the same address as an existing one. Oh and Barry - thanks. It keeps me thinking about stuff, and I learn a fair bit from it. |