Well, this is an overlap on NAT commands and will not work.
Let´s walk through your proposed config and explain why it is not correct (this might help understand the PIX behaviour), so, I will quote some things and explain.
static (dmzMail,outsideBelwue) 1.2.240.60 1.2.240.60 netmask 255.255.255.255 0 0
Correct. The PIX creates a static translation, knows that the address 1.2.240.60/32 is on the dmzMail interface and will proxy-ARP for this address 1.2.240.60/24 on the outsideBelwue interface.
static (dmzMail,outsideBelwue) 1.2.240.52 1.2.240.62 netmask 255.255.255.255 0 0
I believe you made a little typo here (static 52 to 62?), but this one is (like the first one) correct.
static (inside,dmzMail) 1.2.0.0 1.2.0.0 netmask 255.255.0.0 0 0
Here you are getting some troubles, if you are going to set this one. Why?
Well, with this config line you are actually telling the PIX that all 1.2.0.0/16 networks are on the inside interface (and remember, you also stated with the two earlier commands that two addresses within that space were actually on the dmzMail).
Based on this the PIX will proxy-ARP for all the adresses in 1.2.0.0/16 on the dmzMail interface, also for the subnet 1.2.240.0/24 (I think this is the subnet on your dmzMail segment)
The situation you´re getting with this config is also known as overlapping NAT statements, which can be a bitch to troubleshoot in complex configurations and PIX´s with a lot of traffic.
Better thing to do here is use smaller subnetmask, and only set statics to the inside for the subnets within the range that are actually in use
on the inside interface. I know, you have to do some more typing :-S
If you do it this way, you do not need the nat 0 commands, cause the PIX has allready translations in the xlate table due to the static commands in place, so users will allready be able to initiate sessions.
Hope this helps. If more help is needed, do not hesitate to ask.
Kind Regards,
Leo
Same thing goes for the last static command
