Lessons learned from deploying Cisco Firepower Threat Defence firewall virtual appliances in Azure

This is going to be a point form brain dump of some important titbits of information associated with deploying Cisco virtual firewall appliances in Azure. Here we go:

• Azure Network Security Groups (NSGs) are underrated and work really well, with the lack of detailed traffic flow reporting being the only negative
  • I’m sure that will be improved
  • I need to tinker with OMS Log Analytics more and see if that negative is no longer the case
  • NSGs
    • NSGs can be used with the firewall
    • Inbound or outbound rules should state source of TAG Internet not the FTDs themselves
    • The default rules for VirtualNetwork cover the FTD traffic flow
    • Isolating subnets can be achieved still- for DMZs/ Controlled subnets
      • Just deny all other subnets in a VNET address space
      • Do this with low priority rules @ #4000 or higher (max is 4096)
• Firewall interfaces are important, but, not a deal breaker when it comes to routing traffic
  • All you need at a minimum is two interfaces that support routing traffic
  • Ideally you should have three:
    • Untrusted (External, WWW)
    • Controlled (DMZ)
    • Trusted (Restricted and Secured traffic)
  • Cisco Firepower Threat Defence Virtual - Azure only supports routing traffic on TWO of the available 4 interfaces
    • Cisco Adaptive Security Appliance (ASA) Virtual - Azure has 3 interfaces supporting routing of traffic
    • The third interface is designated for Controlled or DMZ traffic / networks
• Cisco Firepower Threat Defence Virtual
  • Each interface must be on a unique subnet
  • A PIP is provisioned on Nic0 which is the management interface
  • Nic1 is used for diagnostics only and does not support routing of any traffic
  • Nic2 can be used for either trusted or untrusted traffic
  • Nic3 can be used for either trusted or untrusted traffic
  • Firepower Management Centre is required for management of the appliance
    • FMC is listed as being required from on-premises
    • Have connected the firewall to FMC via ExpressRoute and MPLS via internal network addresses
    • This leads me to believe an FMC should be able to be deployed in Azure
  • LOAD BALANCING
    • Azure Load Balancers are used to achieve “availability” - true HA isn’t available as the devices are not stateful, and they don’t replicate between each other
      • Devices can be provisioned in an availability set
      • A load balancer sandwich is then implemented
        • ELB for inbound from Untrusted
        • ILB outbound from trusted
      • This ensures that at least one firewall is up all the time- guaranteed by Azure
        • Achieves 99.95% SLA
    • Out of the box, the Azure Load Balancer requires a health probe to ensure that the host or instance its sending traffic too is healthy
    • This health probe is on the same interface that the traffic needs to be going to
    • The Cisco FTDv does not play nicely with this out of the box
    • Solution for this
      • Via Julian Dagher from SecureAgility
        • Get the Azure LB health probe IP (168.63.129.16 via Azure documentation here)
        • Open up a port on both the untrusted and trusted interfaces to only that IP
        • Create a “Platform Profile” on the Cisco FTD
        • This allows for only the Azure health probe to hit that socket on the firewall
        • Finally put a route to the probe IP with the next hop of the inside interface
    • Asymmetric routing is avoided via session persistence configuration on the LB’s - client IP and protocol
• Additional licensing is required for the FTDs deployed from the Azure Marketplace
  • Although a 90 day grace period is available to trail the virtual appliances
• The management controller is advised to be on-premises
  • However, the FTDs were connected to an on-premises FMC via ExpressRoute and private IP’s, rather than public IP’s
  • I don’t see why a FMC wouldn’t be deployed in Azure - that is to be tested one day