What's the point of service-specific NAT if you're not changing the port?

[RayPesek]

I was looking over a rulebase the other day and saw that almost all of the NAT rules are service-specific. FTP servers get manual NAT rules for just the FTP service, mail servers just SMTP, etc. The destination port is always original.

If you're not translating to a different destination port, why would you want to do this? The gateways are a mix of R55 and R61.

I'm wondering if the thought was that port scanning traffic to the destination address would get dropped by virtue of only one service being specified in the NAT rule.

Any thoughts would be greatly appreciated.

Thanks,

Ray

[MarioL]

I can think of a few reasons for that, even though I use automatic static NAT 99% of the time.

1 - Share one IP for multiple services (kind of the NetScreen VIP)
2 - 2nd layer of security, if you mess up the rulebase and allow more than you want (like order or something), the NAT will "stop" it. Really just doubling the work, not something I'd do.
3 - What you said, even though the security policy should handle this.

[dsb.nepo]

I even have such rules but for only one reson.

say you have 2 servers, every server provide http, ftp (mirrored from the other machine).

Normaly you setup nat this way

src  | dest    | proto  || src  | dest   | proto
any  | PubIP1  | any    || =    | NatIP1 | = 
any  | PubIP2  | any    || =    | NatIP2 | =

now take the first server down for maintanance ...

With this setup i can swap NatIP1 with NatIP2 wo. downtime for outside users and serve both http and ftp at one application server.

src  | dest    | proto  || src  | dest   | proto
any  | PubIP1  | http    || =    | NatIP1 | = 
any  | PubIP2  | ftp     || =    | NatIP2 | =

If Server1 is back i only swap the nat objects again.

[RobertGraham]

Yeah, I saw a policy once where the creator used the NAT rules as a way to augment network access control. It was actually over a VPN where they took away services using NAT.

To me, it's not a good idea. It's easy to misconfigure and increases complexity, which doesn't justify the trade-offs.

It's possible to accomplish what dsp.nebo refers to without explicitly defining these rules in advance. You can just create them when you need them.

If you believe as I do that as complexity increases it correlates negatively with security, these rules should be removed for a simplier more straightforward policy. If you can convince the client that this shouldn't be done, they are better off.

[dsb.nepo]

If you believe as I do that as complexity increases it correlates negatively with security, these rules should be removed for a simplier more straightforward policy. If you can convince the client that this shouldn't be done, they are better off.

I agree with you, that is one of the reason the servers where rebuild as cluster.

[RayPesek]

Thanks for the responses and thoughts, folks.

Ray