PIX 501 ACL Help

I have a client who has a pix 501. They have only allowed me web access/PDM to configure it. We are doing offsite email scanning/filtering for them. I would like to create an access rule on the pix 501 to only accept email from our server. This way, we're sure it gets scanned. In the event the offsite service is comprimised, I can just pull that ACL and the backup MX record will take care of mail.

I added a record on the web page which said more or less, the IP (source) of the mail filter, with 255.255.255.255 as the mask, to the internal ip of the mail server, and service smtp was allowed. I actually just edited their current smtp rule. When I did this, mail would no longer come through. When I removed the specific IP and went back to any, mail came right through, AND through that mail filter too.

Any help?

Reply to
chip.bell
Loading thread data ...

That's the error. Unless you are doing VPN work, you need the external IP of the mail server there.

When you are creating an ACL that is to be applied to the outside, you have to imagine that address translation has not yet taken place, so everything has to be written in terms of what the PIX would see "on the wire" -- the external versions of all the IPs.

Conversely ACL entries to be applied inside are done before address translation, so you write what would be seen "on the wire" -- the internal versions of all the IPs.

[I don't just write "source" and "destination" IPs there, because PIX can translate source IPs and destination IPs.]
Reply to
Walter Roberson

Ok, so I would add a rule that says

source ip of the mail filter -----> public IP of the internal mail server?

BTW, thanks for your help...

Reply to
chip.bell

In article , wrote: :Ok, so I would add a rule that says

:source ip of the mail filter -----> public IP of the internal mail :server?

Yes, and if you happen to be using non-standard ports, you would use the public port number, not the internal port.

Reply to
Walter Roberson

Ok cool. Do I need to make a deny ACL to run to prevent other mail servers from connecting?

By the way, thank you very much for your help.

Reply to
chip.bell

In article , wrote: :Ok cool. Do I need to make a deny ACL to run to prevent other mail :servers from connecting?

Everything not permitted is denied, so as long as you have been restrictive on your other ACL entries and you only permit that one source to connect to the mail server, then only it will be let through.

However, if you -have- configured for that kind of protection, then your plan of just "deleting" the entry if need be and having the backup MX work, will not work if the backup MX is inside the protected area.

One thing I have found is that if you have a backup MX configured, then hosts (especially spammers) will use it even though it is not the highest priority (lowest MX number). So... if your backup plan is to allow mail through directly to the inside server without going through your filtering service, then you would want to -change- the entry to permit everything instead of permitting just your one host.

As a practical suggestion: I would suggest that instead of directly coding,

access-list out2in permit tcp host FILTERSERVICE host MAILSYSTEM eq smtp

that instead you code,

object-group network permitted_mailers network-object host FILTERSERVICE access-list out2in permit tcp object-group permitted_mailers host MAILSYSTEM eq smtp

If you do that, then instead of having to edit the ACL line, all you would have to do to allow or disallow the public would be to alter the object group; e.g., after the above, commanding

object-group network permitted_mailers network-object any

would have the effect of -adding- "any" to the list of permitted servers, and

object-group network permitted_mailers no network-object any

would have the effect of removing the public again. That's easier than showing the access list, finding the line number, removing the old entry by line number, inserting the new entry by line number...

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.