Q: What do the choices under the firewall object's "Connection Persistence" dialog mean?

A:

The "connection persistence" settings define how the firewall treats established connections when installing a new policy.

• Keep all connections: Keeps all control and data connections open until the connection has ended. The newly installed Policy will be enforced on new connections only.
• Keep data connections: Keeps all data connections open until the connection has ended. Control connections that are not allowed under the new policy will be terminated.
• Rematch connections: This means that all connections not allowed under the new Policy will be terminated.

Additionally and separately, each service has its own checkbox titled "Keep connections open after policy install", normally not checked. If checked, this service's connections survive a policy install as if "keep all connections" were the global policy, regardless of what the global policy actually is. Therefore, this checkbox overrides the global policy setting.

Q: If I set up a static address translation in one direction, do I need to create a matching rule for the other direction?

A:

On the address translation tab of the firewall policy, if I set up a static translation in one direction, do I need to create a matching rule to translate the return traffic back? If not, why do the "automatic" address translation rules do this? In other words: Rule #1: OrigSrc=any OrigDst=mywebserver public OrigPort=any XlatSrc=original XlatDst=mywebserver private XlatPort=original Must we create this second rule, as the automatic rules do? Rule #2 OrigSrc=mywebserver private OrigDst=any OrigPort=any XlatSrc=mywebserver public XlatDst=original XlatPort=original Seems to work fine without rule #2. So why do the automatic rules do this? working on it...

Q: How do I keep the firewall's SmartDefense from dropping some of my FTP sessions?

A:

The firewall log says some of the FTP sessions are being dropped for "reason: tried to open a known service port". This is a case of the firewall trying to be just a little too clever. It's dropping any FTP sessions from an ephemeral port that happens to be defined as a service port (or part of a range of service ports) in the rulebase, on the off chance that the session is an FTP bounce attack and not part of an actual FTP session. To stop this from occurring, go to the SmartDefense tab in the management console. Navigate to leaf object "Network Security / Dynamic Ports". You can leave "Block data connections to low ports" checked, but choose the radio button for "Allow data connections to all defined services' ports". (Of course, this won't take effect until you install the policy.) This solved the problem for me. I would have thought that the SmartDefense "Application Intelligence / FTP / Prevent known ports checking" would have been the thing to check, but that is still unchecked and the FTP sessions are working.