The Out-of-path deployment mode is commonly used when, one cannot bring down the network. Out-of-path deployment happens to be very difficult to manage as one cannot intercept and redirect the internet traffic at network level (like configuring WCCP, PBR or inline deployment). One needs to explicitly configure the web browser of each client to sent internet request to Proxy SG. Hence this mode of deployment is also known as explicit proxy deployment.
One can use either of the methods to configure the out-of-path / explicit mode to redirect the traffic to Proxy SG
- Client Brower is manually configured to connect to Proxy SG
- System administrator can distribute PAC (Proxy Automatic Configuration) files using group policy to explicitly point the end-user’s browsers to the Proxy SG.
Some of the advantages of Out-of Path deployment are
- No downtime is required to deploy out-of-path mode in any network
- Easy to deploy
Some of the disadvantages of Out-of-Path deployment are
- Requires client configuration to redirect the internet traffic towards Proxy SG
- Increase administrative overheads
In Virtually Inline deployment mode, the Proxy SG can be deployed in any network location, it relies on traffic redirection mechanisms like Web Cache Communication Protocol (WCCP) or Policy Based Routing (PBR) to redirect the interesting traffic, such as HTTP /HTTPS to the Proxy SG. WCCP is a Cisco proprietary protocol that allows certain Cisco routers, switches, Firewalls and Nexus switches to transparently redirect the traffic to a cache engine like Proxy SG. Blue Coat Proxy SG does supports both versions of WCCP 1 and 2.
The main advantages of Virtually Inline Deployment mode are
- No downtime is required to deploy Virtually inline mode in any network
- Very scalable and Robust
- Additional Proxy SG appliance can be added for capacity redundancy.
- The administration overhead is low, as clients need no configurations in their browsers.
Some of the disadvantages of Virtually Inline Deployment mode are
- Network configurations are needed to enable WCCP. This some times creates additional load on the Switch or Router especially when GRE is used.
- WCCP / PBR capable hardware is required for Virtually Inline Deployment.
Virtually Inline mode proves to very handy form operation prespective and its been observed this is one of the widely used deployment method for Blue Coat Proxy SG.
When it comes to deployment of Blue Coat Proxy SG, it offers some flexibility. One can deploy them in either of the below mentioned methods.
- Physically Inline (Transparent)
- Out-of-Path or Virtually Inline (Transparent)
Inline deployment is the simplest among the above mentioned deployments and it well suits for small branch offices. In this mode of deployment, the Proxy SG is placed directly placed between the core Switch and the edge router, logically the Proxy SG is placed in the path of all network traffic going to and from the Internet. In mode the Proxy SG relies on pass-through network card, which basically supports hardware bridging to provide fail-to-wire functionality. This mode of deployment doesn’t require any configuration changes either in core switch or router. Even the clients don’t need any kind of configuration. This mode of deployment is also known as bridge mode due to the hardware bridging network cards in use.
Inline deployment mode does have certain draw backs like
- Single point of failure.
- Network down time is must to deploy inline mode.
- Doesn’t offer scalability.
- Protocols proxied needs to be managed.
Inline deployment holds good for small organization as its is easy to deploy, can be used for evaluations or short-term deployments. However, one cannot rely on this mode for larger organizations for obvious drawback mentioned.
When it comes to deployment of Blue Coat Proxy SG, it can be deployed as a forward proxy or reverse proxy.
Basically forward proxy is used proxy LAN users / Internal user’s requests to the external networks. In this mode of deployment, the Blue Coat Proxy proxies in behalf of client. Basically the tcp session is built between Internal Users and Proxy SG, the proxy then breaks this tcp session and build a new tcp session with the External server. The internet network users are never exposed directly to external servers. In forward proxy mode, the Proxy is always placed on the same network as Internal users.
In the reverse proxy mode, the proxy does the opposite of forward proxy, in this mode the proxy is placed in the same zone as servers. When the external client initiates the connection towards the internal web server, the Proxy intercepts that connection and proxies the whole communication between the external client and the web server. As forward proxy mode , the proxy breaks the tcp session between the external client and the internal web server.
Proxy either in forward or reverse proxy mode always act as layer of protection, and can be used to implement security policies, caching, anti-virus scanning etc.
Blue Coat proxg SG can be physically deployed in following ways.
- Physically Inline (Transparent)
- Out-of-Path or Virtually Inline (Transparent)
In upcoming post, we will discuss these methods in brief.
When it comes to forward proxy or reverse proxy Blue Coat Proxy SG happens to be a Gartner Magic Quadrant leader in Secure Web Gateways category. They are especially known for their proxy capabilities for over a decade Blue Coat offers their Proxy SG appliances in various size and models. More details about their current models and capabilities can be discovered at their website.
Their strengths according to Gartner are
- ProxySG is the strongest proxy in the market in terms of breadth of protocols and the number of advanced features. It also supports multiple authentication and directory integration options.
- Blue Coat’s hybrid offering (cloud service and on-premises appliances) enables operations teams to manage most policies from a single console (although policies can be pushed only in one direction — from the cloud to on-premises appliances).
- Blue Coat provides strong support for SSL/TLS. All ProxySG models include SSL hardware assist, to offload processing from the main CPU. The stand-alone SSL Visibility Appliance can be used to decrypt SSL/TLS traffic and feed it to Blue Coat and non-Blue Coat security solutions (for example, data loss prevention [DLP], IPS and network sandboxes).
- Blue Coat’s partnership strategy has enabled it to fill gaps in its product line. Partnerships with six endpoint detection and response (EDR) vendors help ensure that its customers can complement Blue Coat’s network-based advance threat detection with an endpoint strategy. Partnerships with FireEye and Lastline enable customers to use their own sandboxes instead of Blue Coat’s sandbox. A partnership with Cylance adds signatureless file inspection to Blue Coat’s Content Analysis System.
- Blue Coat’s ownership and integration of CASB technology gives it an early mover advantage in this emerging market
The main intention of starting a series on blogs post about Blue Coat is to create an awareness about Blue Coat especially the technical capabilities of the appliance as its not easy to find more resources on Blue Coat Proxy SG. One need to rely on Blue Coat portal for more details and the information is not easily accessible especially for those who are not aware about the Blue Coat products.
The Cisco ASA Firewall with FirePOWER services can be deployed in Active/ Active failover, in this mode the ASAs must operate in multiple context mode. Cisco is relying on failover groups for active Active/Active failover mode. A failover group comprises of logical groups, of one or more security context. In Active/Active failover mode , both units of Cisco ASA Firewall with FirePOWER services can pass the network traffic, however the traffic load is split between members of the failover pair in such a way that each unit will be active for some set of security contexts.
The Cisco ASA Firewall with FirePOWER services can support up to three fail over groups in Active/Active failover mode.
- Group 0
- This is a hidden group which cannot be modified and it hold system context as its member. Group 0 have huge dependency on Group 1 as Group 0 remains active on the ASA unit where the group 1 is active .
- Group 1
- The admin context is always the part of this group and any newly created context are added to this group by default. By default the primary ASA Firewall with FirePOWER services unit always own the Group 1.
- Group 2
- Some of the newly created contexts can be added to be the part of group 2 so that they are active on the secondary unit of the ASA Firewall with FirePOWER services. By default Group 2 is also active on the primary ASA Firewall with FirePOWER services unit, one need to change ownership of Group 2 from the primary ASA Firewall with FirePOWER services unit to the Secondary ASA Firewall with FirePOWER services unit manually
In Active/ Active failover deployment with multi context mode
- Physical interfaces of the ASA Firewall with FirePOWER services cannot be shared between contexts belong to different failover groups.
- All the features of ASA Firewall with FirePOWER services are not supported
- When failover occurs, a single physical ASA unit must carry all the traffic load which was shared by two ASA units.
- When ASA FirePOWER module fails, it can be configured to do either of the following
- Fail Open
- In fail open state all the traffic will pass thought the ASA even when the ASA FirePOWER module fails
- Fail Close
- In this state all traffic passing though the ASA will stop.
- Fail Open
The Active/ Active failover deployment is quite useful following scenarios
- Multi-tenancy environment
- Multiple LAN subnets which needs a logical separation though different firewalls.
However looking at the limitations of Active/ Active failover deployment model one can consider clustering of Cisco ASA with FirePOWER modules as they provide much better HA solutions for load sharing scenarios.
The Cisco ASA Appliances offers failover in following states
- Stateless failover
- Stateful failover.
By default Cisco ASA Appliance performs stateless failover and in this mode of operation, the Active Unit does the following
- Synchronizes its configuration with the standby unit.
- Maintains all Stateful flow information
- Doesn’t synchronises Stateful flow with the Standby Unit
The Stateless failover is not a viable option, especially when failover occurs as it has to re-establish all the connections. This state simply cannot provide the availability of the services without any disruption. However some hardware platforms like Cisco ASA 5505 are only capable of working in Stateless failover mode.
When Stateful failover is enabled on the Cisco ASA Active unit it is capable synchronizing the following with Standby Unit
- Stateful table for TCP & UDP connection
- Routing table both static and dynamic learned routes
- ARP table
- Bridge-group MAC mapping table in the transparent mode.
- Application Inspection data for certain applications like
- Packet Data Protocol (PDP)
- General Packet Radio Service (GPRS)
- GPRS Tunnelling Protocol (GPT)
- Session Initiation Protocol (SIP) signalling tables.
- VPN Data structures like Security Associations (SA)
However Stateful failover is supported only for the Cisco ASA Software features, where as the Cisco ASA FirePOWER module need to track the connection state independently. When failover occurs ASA FirePOWER flows are transferred to the new Active unit. The ASA FirePOWER module in the new active unit is capable of inspecting the traffic only from that point as old inspection states are not transferred during the failover process.
The Cisco ASA Appliance with FirePOWER Services is capable of offering high availability using failover and clustering. When it comes to failover , the Cisco ASA supports following types
- Active/ Active
The Cisco ASA Appliance with FirePOWER Services when deployed in Active/Standby failover mode it offers device level redundancy. However only one unit of ASA appliance remains in active mode , where as the other ASA Appliance of the failover pair remain in standby mode.
The ASA Appliance in Active mode is responsible for the following
- Active unit accepts all the configuration commands from the user and replicate the same with Standby Unit.
- All transit traffic is processed.
- Applies security policies , build and tear down connections .
- Synchronises all the connection information like global pool addresses, translation table for NAT, TCP/UDP states, ARP table and many other details with the standby unit provided its configured in Stateful failover mode.
- Forwards all the syslog messages and Netflow Secure Event Logging (NSEL) to the destined event or log collector.
- Participates in building and maintaining dynamic routing adjacencies with peer routing device
The standby device is not capable of processing any traffic it receives , it simply drops all the transit traffic and only accepts the management connections. The Standby ASA Appliance becomes fully active automatically, provided that the active ASA appliance becomes less operational healthy than its peer.
When it comes to designing a network one may need to think from many aspects, one such aspect happens to be the scalability. It’s been observed most of the SMBs rely purely on their team to choose the technology or the product. This fits true especially when they want to upgrade their old router with a new one. The challenge of selecting a right product with no design experience is quite hard and often it’s been observed most of the SMBs end up either buying a lower specs device or much high end device. To overcome this challenge for Cisco Routers,Cisco is ffering Cisco Router Selector to select a right router which fits the need of an Organization.
By simply answering few questions one can identity the right Cisco router one might require , currently the Cisco Router Selector allows one to select Branch Routers and Network Edge Routers . The tool recommends the Cisco Edge router based on the encryption throughput, is the router physical or virtual, which is fine for SMBs.
It’s a good offering from Cisco, as one could have an idea of what they want buy, however this tool cannot replace the task of Network designers and architects as they design networks from many dimensions few of them are business need of the customer, functional requirements, technical requirements, user experience etc.
Migrating a Cisco ASA Firewall from older Cisco ASA platform to another Cisco ASA 5500 or 5500-X series platform or even from older ASA Version 7.2 (x), 8.0(x),8.1(x) or 8.2(x) to 9.1 (x) or 9.2(x) version, then one can rely on Cisco FWM portal. This web based portal provides a unified interface to migrate configuration conversions in secured manner to the desired Cisco ASA platform with very little effort.
Firewall migration tools either in form of a virtual machine or a web portal provides good review for the migration planned from one version to another or from one vendor to another. But it’s hard to completely rely on them as they might miss out few things. The Cisco FWM portal provides a good platform to plan the firewall migrations.
The Cisco FWM web portal is quite easy to navigate and does have a good online documentation as well to know how the portal works. Currently Cisco is offering migrations from one Cisco platform to another Cisco ASA platform and the conversion can be done from 7.2 (x), 8.0(x),8.1(x) or 8.2(x) to 9.1 (x) or 9.2(x) version
Cisco is supposed to offer migration for Juniper SRX Firewalls and Checkpoint Firewalls, however currently the its not offered, however Cisco claims this will be offered soon.
The migration process is quite easy, one simply needs to follow the instructions mentioned in the web portal to get the converted file . Based on experience, we recommend not to rely completely on the converted file as there will be few errors in conversion. However, it proves to be a good reference file one could have while planning the migration from one trial version of ASA software to another.