2 Replies Latest reply on Jul 8, 2015 2:37 PM by mike18

    IPv4 port conflict in zone inside


      Hi everyone,


      I was trying to create a access control rule for port 1433 for inside interface.

      When i try to save it i get error



      Ipv4 port conflict in zone inside between agent http_proxy and agent mssql_proxy on tcp port 1433.


      Does this mean that port 1433 is used by 2 applications and there name are http_proxy and mssql_proxy?


      The port conflict must be resolved by forcing all policy rules to use the same agent/application  for this port.


      Does this mean that all policies should use the same application name and port number?


      The http_proxy agent is referenced in the following rule and application sets

      DMZ: SCC_in




        • 1. Re: IPv4 port conflict in zone inside
          Does this mean that all policies should use the same application name and port number?


          Essentially, yes.


          Those who were familiar with older versions of the Firewall Enterprise (and Sidewinder) product had to deal with the same behaviour. You can have multiple service/application definition entries using the same port number, but only one of them can be used per zone. You can use the"mssql" service in a rule from external-to-DMZ, and use a different service/application (using the same port number) in a rule from internal-to-external (as the source zones are different). In v6, this was done by enabling/disabling the service on a per-zone basis and if you tried to enable a service where an existing service using the same port number was already enabled you would see an error. From v7 onwards it was no longer necessary to manually enable a service as it would be automatically enabled as soon as it is used by an access control rule.


          When v8 was first launched and McAfee introduced the concept of Application definitions instead of services it was possible to have more than one application using the same port number applied in the access control rules. However, for reasons (which I will leave someone from McAfee to explain) when 8.3 was released they reverted back to a single active service/port number per zone principle.


          To that end, if you give your application definitions more generic names ("tcp-1433", rather than "sql", for example) when this definition is used in different access rules for different purposes it could be considered to be less confusing for another admin looking at those rules. The rule name can be used to identify the difference. So if you have a rule in place to allow traffic to pass to/from a SQL server, you can use the "tcp-1433" definition, but call the rule something appropriate and if you then need to create an additional rule for another service that just happens to use TCP port 1433 as well, you can use the same definition, but name the rule in a way that makes it clear to another admin what that rule is designed to do.



          • 2. Re: IPv4 port conflict in zone inside

            Many thanks Phil for so great and detailed explanation