Yesterday i was on a customer site helping them with a firewall replacement. They had changed their firewall from one vendor to Cisco and installed a PIX 525 running 7.2.
The PIX had four interfaces, outside, inside, mail_DMZ and VPN_DMZ.
The VPN DMZ contained a Cisco 3005 concentrator, this device had a public IP address and IPSEC from the Internet worked correctly to the 3005.
Web traffic from the inside interface on the PIX destined for the outside worked correctly and was translated to the outside interface IP address via a global statement
Traffic to the mail_DMZ from the inside network was NATed to the mail_DMZ interface IP address which worked correctly.
Traffic from the mail_DMZ to the internal exchange server on the inside network worked correctly
Traffic to the VPN_DMZ from the inside network was NATed to the VPN_DMZ interface IP address which worked correctly.
The problem i had was using a static PAT for mail traffic from the outside destinated for the mail relay server on the mail_DMZ. The customers MX record points to the external IP address of the PIX. The static statement then translated any SMTP packets seen on this address to a private address which was located on the mail_DMZ.
So basically the outside IP address is the global address for outbound traffic from the inside, and is also the static PAT address for inbound and outbound mail which is redirected from a public IP on port tcp 25 to a private IP address on the DMZ on port tcp 25 and vice versa.
Pretty straightforward stuff however SMTP traffic from the internet was not being translated to the private address. When i looked at the NAT traffic i could see there was no translation hits, only misses. When i changed the IP address of the static statement to a spare address then i could happily telnet to the public address of the mail server on port 25, however as soon as i changed it back to the outside IP address i could no longer telnet to the mail server. Also interestingly, the mail relay server also does anti X type services and when the Static PAT was in use using the outside interface the mail relay server could talk outbound to the internet and retrieve it's IDS and Antivirus signatures plus outbound email could also be sent so this issue was with inbound traffic only. The ACLs were definately correct...
The workaround was to change the outside IP address to one of the spare IPs and then have the static using the now spare address that was formerly the outside interface of the PIX as this address was referenced in the customers MX records.
Has anyone every come across an issue like this before, see attachment for config.
I do not see anything wrong in the config. Did you perform a clear xlate after you made the change. Also, I am not sure if you need nat control enabled for this to work.
Hi, yes i did the clear xlate. Now you mention it turning nat-control on is the only thing i didn't try!!, however i did do some reading on it and i believed that if you had nat-control turned off which is the default you could still use NAT if you wanted to, it just means that you don't have to unlike on a pre 7.0 PIX. Plus as the other statics were all working i guess it didn't really cross my mind.
If your MX record points to the external interface, is their any particular reason why you dont use/try:
static (mail_DMZ,outside) tcp interface smtp mail_server_priv smtp netmask 255.255.255.255
Although it would theorectically have the same affect as your current static.
Also, does your hitcount for outside_in increment?
I didn't try this unfortunately and i've probably missed the opportunity now. I'm going the try and lab the scenario on a spare PIX. Yes the ACL hitcount was incrementing but i was seeing translation misses when looking at the output for "show nat".
Maybe this is a bug as in theory and as you mentioned the static is still doing the same thing whether it uses the interface or the IP address of the outside interface. I'll try and lab it and report back as it did give me a headache when trying to do the implementation.
If you have "nat-control" on then any traffic for which there is no defined NAT is dropped (with an error logged). If you have "no nat-control" then any traffic for which there is no defined NAT is passed un-NATed. So I don't think it's the issue here.
The config you posted looks fine but I don't think that's the config you have a problem with. You have a problem if you try to PAT the mail server behind the outside PAT pool address? In theory that should be fine because PAT pool would use ports from 1024 up, but I think I once had a problem with this (years ago) and have always avoided this since then.
I haven't been able to replicate this issue yet as my colleague has been too busy but thanks for all your suggestions.