Cisco ASA in GNS3: Possible Scenarios and Related Bugs
More than one article has been devoted to the GNS3 emulator on the hub, and I think that many who work with Cisco equipment were faced with the need to run network equipment in a virtual environment to check topologies and solutions of interest, when debugging idle configurations, or just in preparation for certification or the study of a particular technology.
Recent versions of GNS3 have the ability to emulate a device such as the Cisco ASA. This device is a multifunctional firewall, can operate in various modes (routed / transparent; single / multiple context), used in fault-tolerant configurations (active / standby; active / active), etc. The article provides test results and conclusions on how fully this functionality is supported when virtualizing this device in GNS3.
I hope that this article will help you decide whether to emulate a particular topology in GNS3, and also save time when debugging your solution in a virtual environment.
Initial data
Testing was carried out using the following tools:
1. Windows Server 2003 R2 Standard virtual machine (Intel Xeon E5420 2.50GHz, 4Gb RAM);
2. GNS3 emulator v.0.7.4;
3. Cisco ASA 8.0 OS image (2);
4. Cisco ASDM 6.4 Graphical Management and Monitoring Tool (5);
5. Cisco IOS OS image for 3725 routers (c3725-adventerprisek9-mz.124-25d);
6. Cisco ACS 4.2 access control server;
7. FTP, TFTP, syslog server based on 3CDaemon.
Test topologies and test methods were taken from the first Internetwork Expert (INE) workbook (WB) to prepare for CCIE Security. I will omit the tasks and a description of the technologies being tested, I will leave only the results.
The description of how to launch Cisco ASA in GNS3 can be found at the links in English , and even in Russian .
In the first test, the firewall (hereinafter referred to as the ME) of the Cisco ASA started in routed and single modes (without support for virtual contexts).
The topology is shown in the figure:
As part of these checks, the operation of dynamic routing protocols (RIP, OSPF, EIGRP), redistribution, IP SLA tracking was checked.
In cases where there was a need for a managed switch, the Cisco 3725 router with the NM-16ESW module was used.
The list of unsupported L2 functions when using the NM-16ESW module is given on the official website .
The command line interface is slightly different from Cisco Catalyst switches. Be careful.
Actually, with the tasks listed in WB1 INE, there were no problems emulating the Cisco ASA. And in general, looking ahead, I’ll say that only routed / single modes work more or less fully in GNS3 at the moment.
However, already at this stage a number of auxiliary bugs appeared. Perhaps the word “bug” does not quite correctly reflect the difficulties and errors that occurred during emulation, but for the sake of unity of classification I will use it.
Bug number 1. The need to reboot the Cisco ASA after setting the basic configuration in case the switching was carried out after the device started. Otherwise, the connection was not established, the devices did not see each other.
Bug number 2.In general, this is not a bug, but a feature of the basic GNS3 settings. Because On the machine where GNS3 was launched, Cisco ACS4.2 was installed, then the ports 2000-2002 were listened directly to ACS itself. And GNS3 uses ports starting from 2000 as console ports for routers by default. Therefore, be careful, you must change these ports when adding a router.
Bug number 3.Router configuration is not saved after turning GNS3 off and on. This bug was observed in older versions of GNS3 on some IOS images, in particular when working with 3700 series routers. In the current version I had no problems working with 3725, but there is information that the problem persists since 3745 ... Although everything is possible here Depends on the emulated image. In general, if someone encounters, then you can try to solve this problem in this way.
In the second test, the Cisco ASA ME also ran in routed, single modes.
In this test, we checked the operation of access lists (ACLs), various NAT options (dynamic NAT, PAT; static NAT, PAT; dynamic policy NAT, static policy NAT, PAT; Identity NAT; NAT Exemption; Outside Dynamic NAT), the ability to control using ASDM, DNS Doctoring function, processing fragmented traffic, passing BGP connections through MEs, multicasting, NTP protocol operation, event logging (syslog, SNMP), ME operation as a DHCP server, traffic policing and shaping.
There were some difficulties with managing using ASDM (you can see video instructions on how to configure ASDM in GNS3 ). After turning on ASDM, the device log is blocked with the following messages:
which complicates debugging a little. You can use filters or disable logging of this message (
Of the critical flaws:
Bug number 4. The Cisco ASA ME as a DHCP server does not work in the GNS3 environment.
In the third test, the operation of the ME in transparent mode was checked. ASA in transparent mode can use only two interfaces (in single mode) for data transfer (and one dedicated interface for control traffic), despite the fact that it can have more interfaces.
In this mode, the full operation of the Cisco ASA in the GNS3 environment is not supported. The Mgmt interface is available when checking from routers, but traffic does not pass through the firewall, despite the fact that attempts to establish a connection on the firewall are displayed.
Actually, because of this, it was not possible to check the operation of mechanisms such as ARP Inspection, Ethertype ACL, Transparent Firewall NAT.
Bug number 5. Transparent mode in Cisco ASA is not supported in the GNS3 environment.
In this mode, two virtual contexts were created: CustomerA, CustomerB.
Interfaces used by the CustomerA context: E0 / 1.121 (InsideA), E0 / 2 (DMZ), E0 / 0 (Outside)
Interfaces used by the CustomerB context: E0 / 1.122 (InsideB), E0 / 2 (DMZ), E0 / 0 ( Outside)
The DMZ and Outside interfaces are shared between contexts.
In GNS3 environment, this mode will be supported only if the
If your scenario does not involve the use of network address translation, then you will not be able to use the same IP and MAC on a shared interface in several contexts.
Bug number 6. The use of virtual contexts is possible only when the command is disabled
In this mode, only one device is active, the second is in a passive state. The devices synchronize the configuration with each other, as well as the table of connection states, which allows not to break already established connections in the event of an active part failure.
During the test, router R1 established a telnet connection to router R2, after which a failure was simulated (by turning off the port of switch SW1 connected to the active ME). Logically, the failover pair should have switched, the telnet connection should have continued to work, because between ME configured statefull-link.
However, in the GNS3 virtual environment, the result was different. Failover pair switching occurred, but the telnet session was interrupted. Moreover, traffic through firewalls stopped working at all. This is due to the fact that, despite the fact that the active part has changed, the cluster continued to respond to ARP requests with the MAC address of the first firewall (although it has already switched to passive mode). After a complete reboot of the cluster pair, the situation has not changed.
Bug number 7. Cisco ASA in failover mode Active / Standby after switching the active device to a passive one stops passing traffic through itself due to incorrect answers to ARP requests.
As far as I know, when emulating the Cisco PIX 7 version, this problem does not occur. Therefore, if necessary, use this solution.
In this mode, both devices are active. This is achieved by using several virtual contexts, some of which are active on one part of the cluster, some on the other.
The check was planned similar to that described in the previous paragraph. However, it ended a little earlier. The reason is as follows: the devices are combined into a cluster, but traffic does not pass through it, because the failover configuration of Active / Active uses virtual mac addresses.
Bug number 8. Traffic does not pass through the Cisco ASA cluster in Active / Active failover mode.
In the last test, a scheme was assembled with redundant interfaces on the Cisco ASA, which allow combining several physical interfaces into a logical one. In this case, only one interface is active, the second is activated only after the failure of the first.
In the test, the switch port disconnected to the active ASA interface was disconnected. After the failure was detected, the second ME interface was to become active. However, in the GNS3 environment, the ME did not, for its part, detect a port disconnection on the switch, and, accordingly, the idle interface continued to be in the active state.
Bug number 9. Switching the redundant interface does not occur when a physical connection fails on a device adjacent to the ME.
Tests have shown that not all Cisco ASA modes of operation in the GNS3 environment are fully supported. Least of all problems arose when using routed, single mode modes. In general, this mode is the most popular and the most complete in terms of functionality. In transparent mode, the firewall did not work correctly.
The mode using virtual contexts is possible in GNS3, but provided that the function of generating virtual mac addresses is disabled, which will not allow implementing a number of scenarios when working with Cisco ASA.
If your goal is to verify that the two ASA devices are merged into a failover cluster, then you can use GNS3. However, in the case of Active / Standby mode, traffic will not go through the cluster pair during switching (in case of failure), and in the case of Active / Active in all cases.
A situation similar to the Active / Standby mode occurs when using redundant interfaces. In the event of an active interface failure, traffic through the ASA will not pass.
I note that all the configurations used in the tests were tested on real equipment and worked without complaints.
Perhaps there are ways to fully launch this or that Cisco ASA operating mode in GNS3, in which case you can arrange a exposure session and share this knowledge in the comments.
If for some people this solution is new, then you can get to know it on the official website - and also watch a “small” 40-minute video from the famous author of CBT Nuggets study guides to prepare for Cisco exams - Jeremy Cioara.
Recent versions of GNS3 have the ability to emulate a device such as the Cisco ASA. This device is a multifunctional firewall, can operate in various modes (routed / transparent; single / multiple context), used in fault-tolerant configurations (active / standby; active / active), etc. The article provides test results and conclusions on how fully this functionality is supported when virtualizing this device in GNS3.
I hope that this article will help you decide whether to emulate a particular topology in GNS3, and also save time when debugging your solution in a virtual environment.
Initial data
Testing was carried out using the following tools:
1. Windows Server 2003 R2 Standard virtual machine (Intel Xeon E5420 2.50GHz, 4Gb RAM);
2. GNS3 emulator v.0.7.4;
3. Cisco ASA 8.0 OS image (2);
4. Cisco ASDM 6.4 Graphical Management and Monitoring Tool (5);
5. Cisco IOS OS image for 3725 routers (c3725-adventerprisek9-mz.124-25d);
6. Cisco ACS 4.2 access control server;
7. FTP, TFTP, syslog server based on 3CDaemon.
Test topologies and test methods were taken from the first Internetwork Expert (INE) workbook (WB) to prepare for CCIE Security. I will omit the tasks and a description of the technologies being tested, I will leave only the results.
The description of how to launch Cisco ASA in GNS3 can be found at the links in English , and even in Russian .
Test Topologies and Verifications
1. Dynamic routing
In the first test, the firewall (hereinafter referred to as the ME) of the Cisco ASA started in routed and single modes (without support for virtual contexts).
The topology is shown in the figure:
As part of these checks, the operation of dynamic routing protocols (RIP, OSPF, EIGRP), redistribution, IP SLA tracking was checked.
In cases where there was a need for a managed switch, the Cisco 3725 router with the NM-16ESW module was used.
The list of unsupported L2 functions when using the NM-16ESW module is given on the official website .
The command line interface is slightly different from Cisco Catalyst switches. Be careful.
Actually, with the tasks listed in WB1 INE, there were no problems emulating the Cisco ASA. And in general, looking ahead, I’ll say that only routed / single modes work more or less fully in GNS3 at the moment.
However, already at this stage a number of auxiliary bugs appeared. Perhaps the word “bug” does not quite correctly reflect the difficulties and errors that occurred during emulation, but for the sake of unity of classification I will use it.
Bug number 1. The need to reboot the Cisco ASA after setting the basic configuration in case the switching was carried out after the device started. Otherwise, the connection was not established, the devices did not see each other.
Bug number 2.In general, this is not a bug, but a feature of the basic GNS3 settings. Because On the machine where GNS3 was launched, Cisco ACS4.2 was installed, then the ports 2000-2002 were listened directly to ACS itself. And GNS3 uses ports starting from 2000 as console ports for routers by default. Therefore, be careful, you must change these ports when adding a router.
Bug number 3.Router configuration is not saved after turning GNS3 off and on. This bug was observed in older versions of GNS3 on some IOS images, in particular when working with 3700 series routers. In the current version I had no problems working with 3725, but there is information that the problem persists since 3745 ... Although everything is possible here Depends on the emulated image. In general, if someone encounters, then you can try to solve this problem in this way.
2. Network settings
In the second test, the Cisco ASA ME also ran in routed, single modes.
In this test, we checked the operation of access lists (ACLs), various NAT options (dynamic NAT, PAT; static NAT, PAT; dynamic policy NAT, static policy NAT, PAT; Identity NAT; NAT Exemption; Outside Dynamic NAT), the ability to control using ASDM, DNS Doctoring function, processing fragmented traffic, passing BGP connections through MEs, multicasting, NTP protocol operation, event logging (syslog, SNMP), ME operation as a DHCP server, traffic policing and shaping.
There were some difficulties with managing using ASDM (you can see video instructions on how to configure ASDM in GNS3 ). After turning on ASDM, the device log is blocked with the following messages:
%ASA-5-402128: CRYPTO: An attempt to allocate a large memory block
failed, size: size, limit: limitwhich complicates debugging a little. You can use filters or disable logging of this message (
no logging message 402128) altogether . Of the critical flaws:
Bug number 4. The Cisco ASA ME as a DHCP server does not work in the GNS3 environment.
3. Cisco ASA in Transparent Mode
In the third test, the operation of the ME in transparent mode was checked. ASA in transparent mode can use only two interfaces (in single mode) for data transfer (and one dedicated interface for control traffic), despite the fact that it can have more interfaces.
In this mode, the full operation of the Cisco ASA in the GNS3 environment is not supported. The Mgmt interface is available when checking from routers, but traffic does not pass through the firewall, despite the fact that attempts to establish a connection on the firewall are displayed.
Actually, because of this, it was not possible to check the operation of mechanisms such as ARP Inspection, Ethertype ACL, Transparent Firewall NAT.
Bug number 5. Transparent mode in Cisco ASA is not supported in the GNS3 environment.
4. Cisco ASA in Virtual Context Mode
In this mode, two virtual contexts were created: CustomerA, CustomerB.
Interfaces used by the CustomerA context: E0 / 1.121 (InsideA), E0 / 2 (DMZ), E0 / 0 (Outside)
Interfaces used by the CustomerB context: E0 / 1.122 (InsideB), E0 / 2 (DMZ), E0 / 0 ( Outside)
The DMZ and Outside interfaces are shared between contexts.
In GNS3 environment, this mode will be supported only if the
mac-address auto( no mac-address auto) command is disabled . This command generates a virtual mac address on a shared interface for each context. A virtual mac is one of the criteria for classifying a package for delivery in the right context. Therefore, when disconnecting, other criteria for classification will be used (entries in active NAT translations).If your scenario does not involve the use of network address translation, then you will not be able to use the same IP and MAC on a shared interface in several contexts.
Bug number 6. The use of virtual contexts is possible only when the command is disabled
mac-address auto, which imposes restrictions on the possible deployment scenarios of the Cisco ASA ME.5. Failsafe configuration in Active / Standby mode
In this mode, only one device is active, the second is in a passive state. The devices synchronize the configuration with each other, as well as the table of connection states, which allows not to break already established connections in the event of an active part failure.
During the test, router R1 established a telnet connection to router R2, after which a failure was simulated (by turning off the port of switch SW1 connected to the active ME). Logically, the failover pair should have switched, the telnet connection should have continued to work, because between ME configured statefull-link.
However, in the GNS3 virtual environment, the result was different. Failover pair switching occurred, but the telnet session was interrupted. Moreover, traffic through firewalls stopped working at all. This is due to the fact that, despite the fact that the active part has changed, the cluster continued to respond to ARP requests with the MAC address of the first firewall (although it has already switched to passive mode). After a complete reboot of the cluster pair, the situation has not changed.
Bug number 7. Cisco ASA in failover mode Active / Standby after switching the active device to a passive one stops passing traffic through itself due to incorrect answers to ARP requests.
As far as I know, when emulating the Cisco PIX 7 version, this problem does not occur. Therefore, if necessary, use this solution.
6. Failsafe configuration in Active / Active mode
In this mode, both devices are active. This is achieved by using several virtual contexts, some of which are active on one part of the cluster, some on the other.
The check was planned similar to that described in the previous paragraph. However, it ended a little earlier. The reason is as follows: the devices are combined into a cluster, but traffic does not pass through it, because the failover configuration of Active / Active uses virtual mac addresses.
Bug number 8. Traffic does not pass through the Cisco ASA cluster in Active / Active failover mode.
7. Redundant interfaces
In the last test, a scheme was assembled with redundant interfaces on the Cisco ASA, which allow combining several physical interfaces into a logical one. In this case, only one interface is active, the second is activated only after the failure of the first.
In the test, the switch port disconnected to the active ASA interface was disconnected. After the failure was detected, the second ME interface was to become active. However, in the GNS3 environment, the ME did not, for its part, detect a port disconnection on the switch, and, accordingly, the idle interface continued to be in the active state.
Bug number 9. Switching the redundant interface does not occur when a physical connection fails on a device adjacent to the ME.
conclusions
Tests have shown that not all Cisco ASA modes of operation in the GNS3 environment are fully supported. Least of all problems arose when using routed, single mode modes. In general, this mode is the most popular and the most complete in terms of functionality. In transparent mode, the firewall did not work correctly.
The mode using virtual contexts is possible in GNS3, but provided that the function of generating virtual mac addresses is disabled, which will not allow implementing a number of scenarios when working with Cisco ASA.
If your goal is to verify that the two ASA devices are merged into a failover cluster, then you can use GNS3. However, in the case of Active / Standby mode, traffic will not go through the cluster pair during switching (in case of failure), and in the case of Active / Active in all cases.
A situation similar to the Active / Standby mode occurs when using redundant interfaces. In the event of an active interface failure, traffic through the ASA will not pass.
I note that all the configurations used in the tests were tested on real equipment and worked without complaints.
Perhaps there are ways to fully launch this or that Cisco ASA operating mode in GNS3, in which case you can arrange a exposure session and share this knowledge in the comments.
If for some people this solution is new, then you can get to know it on the official website - and also watch a “small” 40-minute video from the famous author of CBT Nuggets study guides to prepare for Cisco exams - Jeremy Cioara.