permit same-security-traffic

The entire basis of the pix is to deny everything unless specifically permitted. It's what the old Pix did.

Yes. Prior to 7.0 Pix, it was not possible to enable this at all.

Thank you for your feedback. Is there any danger of enabling this on the firewall? From your response, I judge that there is no way to enable this only on a specific interface, but needs to be enabled globally?

AL

I can't answer further since I don't really know much about the pix. I do know that Checkpoint for example make virtually no distinction regarding interfaces. The security rules are applied irrespective of the interface that traffic arrives on or departs from. You do have to specify an "external" interface but it is not used (I am reasonably sure:) for the security rules. (NAT maybe, licensing definately - hosts on Internal interfaces are counted.)

So - there is nothing inherently bad about same interface traffic that I can think of.

Afaik that command enables the so called feature "vpn hairpinning" that is the chance for different vpn tunnels terminated on the same interface to talk to each other. As long as you don't have any vpn's terminated on an interface that comand doesn't have any effect on the interface itself. Even on interfaces with vpn's terminated on it the command doesn't do nothing until you properly configure the crypto acl's. Unless I miss something... Bye, Tosh.

Let me explain what I am trying to accomplish. I have a mail server (A) which resides on one interface of my firewall. Mail server's default gateway is the firewall. There is a MX record (another SMTP server - call it B) that resides on the same interface of the firewall (different IP address of course). Sometimes my mail server (A) needs to send emails to MX record of mail server B. The packets are being sent to the firewall (default gateway of server A), but are not routed back to server B. I am not sure whether lack of "same-security-traffic permit intra-interface" is causing it, but it looks like it it. Can you please confirm whether I am on the right track?

Thanks, AL

Probably not. Chances are server A is trying to reach public IP of server B. You can do two things -

1. Enable DNS doctoring -

1. Make sure resolver on server A is using hosts file besides DNS servers and put a mapping between server B name (as listed in MX record) and internal IP.

Regards, Andrey.

Not sure what you mean. Server A is trying to access server B via its MX record which resides in the DMZ. That I am sure. So what is preventing it from accessing it? A packet needs to leave server A via its DMZ IP address then hits the firewall and should come back via the same firewall's interface to reach DMZ IP of server B. However, the packet never reaches server B. I thought that the line in my original post will allow it as it seems to be disabled by default by the firewall.

Thanks, AL

Is firewall doing NAT for those servers? How name resolution is done?

Most common scenario which causes problem you described - NAT is in place, name resolution is done via externally hosted DNS server. In that case when server A queries DNS for MX record, it gets external IP of server B in reply. It tries to establish a connection via firewall (since it's default gateway) and firewall drops SYN packet because it can't NAT it properly. Permit same-security-traffic is not going to help. How to check if that is the case - look for log/syslog entries with DMZ IP of server A and public IP of server B (could be names if you use them in configuration)

Regards, Andrey.

Andrey,

Thanks for the thorough explanation. I think that this can be the case then. Is there a quick way to "grep" through the log messages stored on the firewall? I have logging enabled and messages are being sent to the buffer, but I am not sure whether there is something similar to tcpdump on a cisco firewall (which would allow me to specify both hosts and watch the traffic in real time displaying only the events that I am interested in).

Regards, AL

As a matter of fact - both grep and tcpdump are available. Here is the description of filters for "show" commands -

For tcpdump you need to check "capture" command.

Regards, Andrey.

Thanks a lot for your help.