I have been working on a customer configuring an HA pair of S3008 appliances running v8.3.0P01 in order to replace a pair of old 510 appliances running 7.0.1.02.
Some of the underlying configuration (interface settings & network objects in particular) was exported and imported without too much problem. The time consuming aspect was always going to be the custom-defined services/applications and the rules because there were lots of each - approximately 250 rules. Quite a few of their custom services on v7 had modified timeout values, so I knew that I was going to have to replace that aspect with a range of generic application defenses.
Between us the customer & I have been translating the v7 rule configuration into v8 rules. Two and half days into this process we reached rule #166 and all of a sudden things seemed to go very wrong. This rule was their generic Internet Services rule and was esentially the first rule with a source of internal/any and a destination of external/any.
As soon as we tried to save this rule the following error appeared (with some details substituted for anonymity):-
NAT setttings on rule 'test-rule-1' conflicts with NAT settings on rule 'Outbound-Services': nat_addr=ipaddr:FW-EXT-188.8.131.52 and nat_addr=ipaddr:Localhost.
What we first noticed was that the FW-EXT network object was actually the same physical IP address as Localhost (the primary external IP address), and so we went about changing the rule so that the NAT values matched-up. When we tried apply the changes, the error returned but with a different conflicting rule. So we embarked on an exercise of addressing each conflicting rule until we reach a rule which, upon closer inspection made me wonder why this problem was happening at all.
If the source and destination criteria of a rule were the same, and the application was also the same, I could easily see how differing NAT values could cause the Firewall some confusion. But, in the end, the only conclusion I could reach regarding the similarities of these rules were that they all used either HTTP or SSL. However, in every case I could see there was some kind of explicit reference in either the source endpoint or destination endpoint component. So why should this result in this NAT error?... Surely the Firewall can see that rule #1 with its specific source and/or destination components is sufficiently different to a rule further down the list which shares the same application definions but with source & destinations set to <Any> and on that basis I would expect it to have no issue with the fact that rule #1 is NATing to a specific external IP address while the more generic outbound rule is using Localhost?
Its likely that the customer will have to raise this as a ticket as he sees it as genuine problem (considering the same rules on his v7 installation have no such issues). But I am trying to understand why this happens in v8 and what can be done to combat it?
NAT conflicts like this usually occur when traffic could possibly hit two (or more) different rules that have different applications. In order for the firewall to identify some applications, it needs to allow some of the data. Since we need to allow some of the data before identifying an application and choosing a rule, we need to know a few things ahead of time including the NAT address, IPS settings and App defenses. If those rules that the traffic could possibly match have different settings, the firewall will complain about this when trying to save.
In your case, it seems that the rules do overlap, even though one has a more specific source/destination.
Hope this helps,
So the key trigger is just the service then? I guess my confusion came from the fact that while the service was a common element for these rules, the source and/or destination was always different meaning that, to the eye, there was no obvious reason for the clash.
I am going set up a test v7.0.1.03 system, create a couple of outbound http/https rules with different sources and different NAT values and will then run through the 70103UP812 process to see what comes out the other end.
I guess the point of conjecture (and its not the first time you've mentioned this "needing to allow some of the data to pass before choosing a rule") is that in the eyes of my customer as a standard MFE administrator he's gone from v7, a product which has a pretty intuitive managemet GUI, to v8 which throws up these errors and actually requires the rule set to me somewhat more complicated than before.
Do you see a time where v8 will be able to work this out for itself without needing to pepper the rule set with TCP/UDP deny rules?
I'm curious, the two rules you are talking about have totally different source/destinations, or do they overlap at all? In my mind, if the source/destinations do not overlap at all, then it should not conflict.
That was my point, Matt.
As far as I could tell the only similarity I could see was the applications being used (either HTTP, SSL/TLS, or both). Between us, the customer & I had created 160+ rules of which at least 10 were outbound rules using these two services. The Firewall had no problem with them at all until at position 166 we created the "Outbound Services" rule, which was the first occurance of HTTP, SSL and where the source & destination endpoints where both set to "Any". It was at that point that it all started to unravel.
Initially we wondered if the firewall was being picky about the fact that the Oubound Services rule was NATing to "Localhost" whereas the rules it was complaining about were NATing to a specfic IPAddr object which just happened to be the same address. We went about changing these rules, one by one, so that they all referred to "Localhost" and then it took issue with a rule which I then realised was configured to NAT to a different IPAddr object, but the source/destination criteria of the rule was very specific - from a specific host endpoint to a specific destination endpoint (both represented by IPAddr objects also). When I temporarily disabled this rule, it then took issue with a rule which was using a Netmap object as it's source - which I'd created to consolidate a group of 10 rules (all of which shared the same application and destination criteria, but had different source endpoints and NAT values) and, of course that really left me scratching my head because I didn't know how I could overcome this.
The only way we could move forward with the configuration was to disable the "Outbound Services" rule, but at some point before the system is commissioned live we will need to work out what to do to allow this rule to be in place without it clashing with others.
I probably will, but was using the forum to try and understand "why" this was happening so that I could provide my customer with a suitable explanation.
I have also noticed with v8 that the "Interactions" tab appears to alternate between working and broken depending on the installed patches. As of 8.3.0P01 it appears to be broken. To demonstrate it, I greated a random rule and then positioned it below deny all (which as we all know, means that it won't work). When I selected this rule and clicked on the Interactions tab, I expected it to show the Deny All rule with all the boxes highlighted in red (and with a red ! icon next to the position value), but it didn't.
The installation I have access to in the office is still running 8.2.1 and when I take a rule and move it below Deny All the Interactions tab lights up like a Christmas tree. I've also just tried it on a customer's system who are running 8.3.0 and it also seems to be working, so I can only assume that 8.3.0P01 is where the problem returns. I can't access this customer's appliance as it is in a dark network which I have no access to over the Internet.