WAF - a couple of learning points (learnt the hard way)

Last year, I replaced some clustered Cisco ASA 5510's with some clustered SG310's.

There was a fair amount of work to do as you simply could not export the rules and the terminology was a bit different. Nonetheless, the SG310's went in smoothly and we've been in the adhoc process of adding more and more functionality to users that the UTM's offer.

Part of this is WAF which we are using to retire the last ASA 5510 out as this is solely being used as a clientless SSL vpn (using java)

So I've been coming back to this a bit at a time as we discovered issues that took a little thinking about. The main root of our problems was DNS although you probably wouldn't have thought it was this looking at the errors.

The two big mistakes I made was:

1. Apply request routing for DNS for our external domain. As it was a new concept to us, we applied this from the UTM to all of our internal domain namespaces which was ok at the time for us to do due to the way our DNS was previously setup. We now have it setup so internal clients > internal dns servers > UTM. The UTM is the only device to perform recursive requests to the web.
The big mistake at the time was to apply DNS request routing  to our external domain from the UTM.

Our internal network is like any other eg 6 DNS servers with the internal domain and the external domain as well so that any external clients trying to get to serverA.mydomain.com would be able to use the internal ip address when they were inside the network and use the external public ip address when they were outside the network.

By getting the UTM to request route to the external DNS namespace on our internal DNS servers, the UTM was resolving serverA.mydomain.com to the internal ip address when it should have been resolving it to the external public ip address.

This had a massive detrimental effect on WAF. It was getting confused with the FQDN's. This wasn't noticed until we attempted to implement WAF

So, think very carefully when applying request routing on DNS and never "request route" the external domain name which you want WAF to use.

2. The 2nd issue was again a DNS issue and the mistake here was to add additional external hostnames to a host entry/definition on the UTM. So the UTM would see our internal  web server as an internal private ip but resolve the hostnames of the internal as well as the external hostname. Again, this caused confusion for the poor old WAF which by now, didn't know whether it was coming or going.

Bottom line is when using WAF (or the UTM) is to make sure it doesn't get confused with internal hostnames and external hostnames. So if you have an external FQDN pointing to an internal server, make sure that the UTM can only resolve the external FQDN to the external public ip and the internal server FQDN to the internal private ip. If it can resolve the external to the internal and vice versa, it will get confused and offer up mixed results that sometime work and sometimes don't.

Hopefully this will help somebody in the future and I think the moral of the story is:

The UTM offers a whole host of functionality but please be 100% sure as to what they mean before applying them otherwise you could end up with unpredictable behavior.