Virtually Jason

One of my customers has been deploying App Volumes, using their SQL Always On availability group for the database.  They pointed at the listener and everything looked good... until they initiated a failover.  Fortunately, the fix was really simple, although two part. First, we noticed that the ODBC connections were using the default "SQL Server" driver.  That immediately stood out to us as a problem, as that driver can't handle AO failovers (exactly what we saw).  So, we switched it over to the Microsoft ODBC Driver 13 for SQL Server driver and figured that we'd be good to go.  Almost. When we attempted to connect to the App Volumes Manager, we received a DB access error.  We saw that it was using the correct driver (yay!), but it was getting a credentials error because it was trying to use the server's computer account.  Some quick google searching pointed me at an article about changing database credentials in App Volumes , but that was for a fairly old vers

As a next-gen firewall, NSX allows us to get very dynamic with our firewall rules and create complex behaviors out of comparably very few rules.  Let's look at the same example 3 Tier Application rule set that I wrote about in my post about the Direction and Applied To fields in NSX Firewall rules  post, and look at how these groups could be configured and then we can look at how these rules could be made even more secure.  First though, here's the example rule set: Source Destination Action Applied To Any InfraServices Allow DFW Client Devices Web Allow Web DB, App Web Deny Web Web App Allow App DB App Deny App App DB Allow DB Web DB Deny DB SolutionA SolutionA Allow SolutionA SolutionB SolutionB Allow SolutionB SolutionA Any Deny SolutionA SolutionB Any Deny SolutionB These rules will allow default 3 Tier Application communications (Web can talk to App, App can talk to DB) while blocking nonstandard communication within the solution and blocking all commu

I've had the chance to learn about NSX lately, which has included really diving in to how the firewall behaves.  While it can certainly be used very much like a traditional firewall, you're not doing yourself any favors by doing so.  Remember, this is a policy-based firewall, so our goal is to define as many general behaviors as possible and then have them apply intelligently to the correct VMs based on attributes such as Security Tags. There's a lot to dig into on this topic, but for now I want to focus on two attributes of a firewall rule: Direction and Applied To.  These two settings can be used to dramatically simplify a firewall configuration and can lead to some unexpected results if not used correctly (also, they took me quite a while to wrap my head around). The most important thing to remember is that, like all firewalls, NSX eventually boils down to a sequential list of rules.  NSX will do whatever action is specified in the first rule to match a given flow.