I've been working with one of my customers over the past couple of days and have come up against something which has left us scratching our heads. Though, I'm sad to say, with v8 scratching my head is becoming an all-too-frequent occurrence.
His HA cluster was running very slowly and as the culprit appeared to be DNS-related and he was only running 8.3.0, I recommended that he put 8.3.1 and 8.3.1P01 on the cluster as quickly as possible given there were specific references to fixes for BIND. He did so and that problem, thankfully, went away.
Having encountered no previous issues with his configuration, we were both surprised that the upgrade process initially failed claiming that a couple of his rules were in conflict with others on the appliance. To allow him to get the patches installed as quickly as possible I suggested that he edit these two conflicting rules and replace the application with something completely innocuous and when the patches had successfully installed he could try to put them back again.
In trying to do so, he is now seeing in the GUI the same error he encountered when first trying to install the patches.
"IPv4 port conflict in zone internal between agent http_proxy and agent ssh_proxy on TCP port 22. The port conflict must be resolved by forcing all policy rules to use the same agent/application for this port. The http_proxy agent is referenced in the following rule and application sets:
<Rule name> : SFTP
The ssh_proxy agent is references in the following rules and application sets:
<Rule name> : SSH
<Rule name> : SSH
<Rule name> : SSH"
When I look at the application definition the customer has created for the application "SFTP", it is a plain and simple Infrastructure Service.
Basically when the rule was first created it was to allow an outbound SFTP connection, but for reasons I assume to be related to Sam Leidl's document about how v8 applications and defense groups working, it did not work when using the SSH application. So the "SFTP" infrastructure service was created to stop the firewall from trying to "insert itself" into the conversation.
As mentioned, prior to the 8.3.1 upgrade, creating this infrastructure service and rule didn't result in any errors - and the connection worked.
What is most confusing about this error is the apparent insistence that the SFTP application and the rule which it is being used in are somehow causing the firewall to use the http_proxy agent. I have suggested to my customer that he use an application defense group which has HTTP set to "None" just to be safe. But this still results in the error when he tries to save the rule.
Any inisght would be very helpful.