Posts with #cisco & cisco network tag
In the article “How to Configure a GRE Tunnel?” we talked about what tunneling is and how to configure a GRE Tunnel…In this article we continue to say something about the GRE tunnel and IPsec tunnel—what are the differences?
Encapsulating a packet for secure transportation on the network can be done using either GRE or IPsec protocols. This tip explains under what circumstances each protocol works best.
Generic Routing Encapsulation (GRE), defined by RFC 2784, is a simple IP packet encapsulation protocol. GRE is used when IP packets need to be sent from one network to another, without being parsed or treated like IP packets by any intervening routers.
For example, in Mobile IP, a mobile node registers with a Home Agent. When the mobile node roams to a new network, it registers with a Foreign Agent there. Whenever IP packets addressed to the mobile node are received by the Home Agent, they can be relayed over a GRE tunnel to the Foreign Agent for delivery. It does not matter how the Home Agent and Foreign Agent communicate with each other -- hops in between just pass along the GRE packet. Only the GRE tunnel endpoints -- the two Agents -- actually route the encapsulated IP packet.
The IP Security (IPsec) Encapsulating Security Payload (ESP), defined by RFC 2406, also encapsulates IP packets. However, it does so for a different reason: To secure the encapsulated payload using encryption. IPsec ESP is used when IP packets need to be exchanged between two systems while being protected against eavesdropping or modification along the way.
For example, in a site-to-site VPN, a source host in network "A" transmits an IP packet. When that packet reaches the edge of network "A" it hits a VPN gateway. VPN gateway "A" encrypts the private IP packet and relays it over an ESP tunnel to a peer VPN gateway at the edge of network "B." VPN gateway "B" then decrypts the packet and delivers it to the destination host. Like GRE, it doesn't really matter how the two VPN gateways communicate with each other -- hops in between just pass along the ESP packet. But unlike GRE, someone at those hops could not possibly look at or change the encapsulated IP packet, even if they wanted to. That's because cryptographic algorithms have been applied to scramble the IP packet and detect any modification or replay.
Use GRE where IP tunneling without privacy is required -- it's simpler and thus faster. But, use IPsec ESP where IP tunneling and data privacy are required -- it provides security features that are not even attempted by GRE.
- IPsec stands for Internet Protocol Security while GRE stands for Generic Routing Encapsulation.
- IPsec is the primary protocol of the Internet while GRE is not.
- GRE can carry other routed protocols as well as IP packets in an IP network while IPSec cannot.
- IPsec offers more security than GRE does because of its authentication feature.
More Related Topics
Simplify Access Control without Network Redesign
What’s the Cisco TrustSec Software? What benefits will you get from this Security Solution? You should read some tips about this. Nowadays, we know that business demand for cloud services, mobility, and the Internet of Things (IoT) has created exponential network growth and complexity. It has introduced risk, too. Each new user, device, and data connection represents a potential attack entry point. So your attack surface is expanding. How to deal with these? Now you can control the situation with Cisco TrustSec. Embedded in your existing Cisco network infrastructure, the TrustSec security solution simplifies the provisioning and management of network access control. It uses software-defined segmentation to classify network traffic and enforce policies for more flexible access controls. Traffic classification is based on endpoint identity, not IP address, enabling policy change without network redesign.
TrustSec is powered by the Cisco Identity Services Engine. The centralized policy management platform gathers advanced contextual data about who and what is accessing your network. It then uses security group tags to define roles and access rights and pushes the associated policy to your TrustSec-enabled network devices, such as switches, routers, and security equipment.
You get better visibility through richer contextual information, are better able to detect threats, and accelerate remediation. So you can reduce the impact and costs associated with a potential breach.
What are the Main Benefits You can Get?
• Quickly isolate and contain threats using technology already in your network.
• Limit the impact of data breaches by dynamically segmenting your network.
• Centrally apply and enforce granular and consistent policies across wired, wireless, and remote-access users and devices.
• Reduce operational expenses by defining firewall and access control rules based on asset or application context.
• Easily provide dynamic campus segmentation to enforce security policies in quickly changing environments without provisioning and maintaining access control lists.
• Cater to changing workforces and business relationships by defining security groups based on business roles, not IP addresses.
How It Works
Traditional network segmentation approaches use IP-address-based access control lists (ACLs), VLAN segmentation, and firewall policies that require extensive manual maintenance. Cisco TrustSec simplifies the effort by dynamically grouping machines into objects, called security groups, and provisioning security policies between those objects.
The interaction of systems is determined by the security-group-based policies, eliminating the need for VLAN or address-based policy provisioning. TrustSec is available in virtual and physical switches and treats virtual and physical workloads across the campus and data center consistently.
“Effective network segmentation... reduces the extent to which an adversary can move across the network.”
US Department of Homeland Security
United States Computer Emergency Readiness Team
VSS is network system virtualization technology that pools multiple Cisco Catalyst 6500 Series Switches into one virtual switch, increasing operational efficiency, boosting nonstop communications, and scaling system bandwidth capacity to 1.4 Tbps. Switches would operate as a single logical virtual switch called a virtual switching system 1440 (VSS1440). VSS formed by two Cisco Catalyst 6500 Series Switches with the Virtual Switching Supervisor 720-10GE.
In a VSS, the data plane and switch fabric with capacity of 720 Gbps of supervisor engine in each chassis are active at the same time on both chassis, combining for an active 1400-Gbps switching capacity per VSS. Only one of the virtual switch members has the active control plane. Both chassis are kept in sync with the inter-chassis Stateful Switchover (SSO) mechanism along with Nonstop Forwarding (NSF) to provide nonstop communication even in the event of failure of one of the member supervisor engines or chassis.
The Cisco Catalyst 6500 Series Virtual Switching System (VSS) 1440 allows for the merging of two physical Cisco Catalyst 6500 Series Switches together into a single, logically managed entity. The following figure graphically represents this concept where you can manage two Cisco Catalyst 6509 chassis as a single, 18-slot chassis after enabling Cisco Virtual Switching System.
The Cisco Catalyst 6500 Virtual Switching System (VSS) 1440 takes the flagship Catalyst 6500 platform to the next level with network system virtualization.
Virtual Switching System 1440 Redundancy State
Creating a VSS 1440
The key enabler of a VSS 1440 is the Virtual Switching Supervisor 720-10G. Any two Cisco Catalyst 6500 Series Switches with this supervisor engine can be pooled together into a VSS 1440*. The two switches are connected with 10 GbE links called Virtual Switch Links (VSLs). Once a VSS 1440 is created it acts as a single virtual Catalyst switch delivering the following benefits:
- Two Catalyst 6500s share a single point of management, single gateway IP address, and single routing instance
- Eliminates the dependence on First Hop Redundancy Protocols (FHRP) and Spanning Tree Protocol
- Delivers deterministic, sub-200 millisecond layer 2 link recovery through inter-chassis stateful failovers and the predictable resilience of Etherchannel
Scales to 1.4 Tbps
- Scales system bandwidth capacity to 1.4 Tbps by activating all available bandwidth across redundant Catalyst 6500 switches
- Up to 132 ports of 10 GbE per system
What are the benefits of using VSS?
VSS offers superior benefits compared to traditional Layer 2/Layer 3 network design. VSS increases operational efficiency by simplifying the network, reducing switch management overhead by at least 50 percent. Single point of management, IP address, and routing instance,Single configuration file and node to manage and you won’t have to configure two switches with identical policies and other config. It eliminates the requirement for HSRP, VRRP or GLBP and you have to use just one IP address instead of three used with any FHRP.
Multi chassis Ether Channel (MEC) is a Layer 2 multipathing technology that creates simplified loop-free topologies, eliminating the dependency on Spanning Tree Protocol, which can still be activated to protect strictly against any user misconfiguration and with X2-10GB-ER 10 Gigabit Ethernet optics, the switches can be located up to 40 km apart.
Inter-chassis stateful failover results in no disruption to applications that rely on network state information (for example, forwarding table info, NetFlow, Network Address Translation [NAT], authentication, and authorization). VSS eliminates L2/L3 protocol reconvergence if a virtual switch member fails, resulting in deterministic subsecond virtual switch recovery.
By activating all available Layer 2 bandwidth across redundant Cisco Catalyst 6500 Series Switches with automatic, even load sharing. Link load sharing is optimized because it is based on more granular information, such as L2/L3/L4 parameters, unlike virtual LAN (VLAN)-based load balancing in Spanning Tree Protocol configuration.
More video about VSS
VSS on the 4500
At the end of July, Cisco has quietly announced a new addition to the UCS family–a mini Fabric Interconnect, called the UCS 6324 Fabric Interconnect, which unlike the ones before it plugs directly into the UCS 5108 chassis. With connectivity for up to 15 servers (8 blade servers and up to 7 direct-connect rack servers), the Cisco 6324 is geared toward small environments.
“The 6324 FI is out! What amazing hardware! This is a whole UCS in a 5108 Chassis. Now what I wonder is if this is just code? Being able to take a single chassis and install proper code and have a stand-alone UCS would be GREAT. This will be “Cool” if it is a special chassis, but a GAME CHANGER if any chassis will do with code only (and maybe certain models of IOM’s that might be on hand anyhow).” Some Cisco fans said like that.
Appear’s a new IOM is needed to make this work in a 5108 Chassis.
Cisco introduces Cisco UCS 6324 Fabric Interconnect like that.
The Cisco UCS 6324 Fabric Interconnect is a 10 Gigabit Ethernet, FCoE, and Fibre Channel switch offering up to 500-Gbps throughput and up to four unified ports and one scalability port.
The Cisco UCS 6324 Fabric Interconnect extends the Cisco UCS architecture into environments with requirements for smaller domains. Providing the same unified server and networking capabilities as in the full-scale Cisco UCS solution, the Cisco UCS 6324 Fabric Interconnect embeds the connectivity within the Cisco UCS 5108 Blade Server Chassis to provide a smaller domain of up to 15 servers (8 blade servers and up to 7 direct-connect rack servers).
CISCO 6324 FI Overview
Each 6324 FI module contains:
- 16 x 10GbE internal ports (2 per 1/2 width slot)
- 4 x 10Gb SFP+ external uplink ports
- 1 x 40Gb QSFP+ scalability port
- 1 x 10/100/1000 Mbps Management port for out-of-band management
The 4 external uplink ports can be configured as 1/10 Gigabit Ethernet or 2/4/8-Gbps Fibre Channel ports. The scalability port is designed to allow for connectivity to up to 4 x UCS rack servers with a post-release feature of also allowing a 2nd UCS 5108 chassis to interconnect.
The 6324 FI provides Layer 2 forwarding with support for:
- VLAN trunks
- IEEE 802.1Q VLAN encapsulation
- Support for up to 512 VLANs and 32 virtual SANs (VSANs) per interconnect
- Jumbo frames on all ports (up to 9216 bytes)
- Link Aggregation Control Protocol (LACP): IEEE 802.3ad
- Internet Group Management Protocol (IGMP) Versions 1, 2, and 3 snooping
- Advanced EtherChannel hashing based on Layer 2, 3, and 4 information
- Pause frames (IEEE 802.3x)
- Layer 2 IEEE 802.1p (class of service [CoS])
It is also rumored that UPDATED–based on the information from UCSGuru (below)
a new an updated UCS 5108 blade chassis will be coming out soon which will allow for heartbeat and cluster connectivity between the UCS 6324 FI modules inside a chassis as well as support for “dual voltage” power supplies. Is that real? We are looking forward to it.
The IEEE 802.3 Power over Ethernet (PoE) standard sets the maximum power that can be sourced by data terminal equipment (DTE) at 30W. This power is sourced over two pairs out of the four twisted pairs of conductors in a Class D, or better, cabling as specified in ISO/IEC 11801:1995.
Cisco Universal Power over Ethernet (UPOE) is a Cisco proprietary technology that extends the IEEE 802.3 PoE standard to provide the capability to source up to 60W of power over standard Ethernet cabling infrastructure (Class D or better).
Why Should I Care About Cisco UPOE?
Power over Ethernet has long been hailed as the single most critical innovation that has revolutionized and expedited the adoption of IP telephony in the enterprise market segment. The power rating for electronic products is trending down through advances in semiconductor technology, and the cost of power itself is trending up. UPOE extends the benefits offered by PoE technology to a much wider range of devices due to the higher power envelope.
Some of the key primary benefits of UPOE are:
•Cisco UPOE offers high availability for power and guarantees uninterrupted services; a requirement for critical applications (e911).
•Cisco UPOE lowers OpEx by providing network resiliency at lower cost by consolidating backup power into the wiring closet.
•Cisco UPOE enables faster deployment of new campus access networking infrastructures by eliminating the need for a power outlet for every endpoint.
•Cisco UPOE, in combination with Cisco EnergyWise, helps meet corporate sustainability mandates while lowering energy costs.
What Applications and End Devices Does Cisco UPOE Enable?
Cisco UPOE simplifies network infrastructures, extends high availability for power (PoE resiliency), and delivers lower total cost of ownership for connected environments such as virtual desktop infrastructure (VDI), financial trading floor, enterprise workspace, conference rooms, hospitality guest suites, and retail. Partnerships with industry leaders and in-house development together have resulted in a variety of end devices that are compatible with Cisco UPOE. A few notable end devices are:
•Samsung integrated display VDI zero clients
•LG Electronic Monitor using UPOE Power Splitter
•BT, IPC and SpeakerBus IP Turrets
•Cisco Catalyst compact switches
•Personal Cisco TelePresence systems
•Building management and physical security device
What Primary Verticals Does UPOE Address?
UPOE and the associated partner ecosystem (Cisco Developer Network) provide solutions for the following verticals:
•Financial trading floor
•Enterprise facilities management
What Is the Effect of Cisco UPOE on Heat Dissipated Within the Cabling Infrastructure?
Cisco UPOE is an efficient mechanism for power delivery since it uses all the four twisted pairs of conductors within the Ethernet cabling to deliver power (as opposed to two twisted pairs used by PoE+). This effectively reduces the channel losses by half for the same power delivered over UPOE vs. PoE+. Moreover, the recommendation published by cabling standards — ISO/IEC and TIA/TR-42 as part of formal liaison communiqué with IEEE 802.3 — indicate that UPOE can be supported over the same standard cabling infrastructures that conform to PoE+ requirements.
On Which Switching Platform Is Cisco UPOE Being Introduced?
Cisco UPOE is being introduced on the Cisco Catalyst 4500E Series Switches, the most widely deployed modular access switching platform in the industry. The platform has time and again demonstrated leadership in this space, specifically with PoE+, where the Cisco Catalyst 4500 was the first enterprise-class switch to deliver PoE+ compliant switches, two years to the introduction of the IEEE PoE+ standard. UPOE is being introduced on the Cisco Catalyst 4500E platform in the form a new E-Series line card, WS-X4748-UPOE+E, that is compatible with Supervisor Engine 8-E, 7-E, 7L-E and beyond. Cisco UPOE is backward compatible with both PoE (IEEE 802.3af) as well as PoE+ (IEEE 802.3at).
What Is the UPOE Scalability on a Cisco Catalyst 4500E System?
Each WS-X4748-UPOE+E line card has a total available power budget of 1440W that can be allocated to the 48 front panel ports with a maximum of 60W per port. This provides the capability to power a maximum of 24 ports simultaneously at 60W. With five such line cards on a single system, the maximum number of ports that can simultaneously source 60W is 116. Moreover, each port also supports LLDP-based dynamic power negotiation capability that permits the end device to communicate the exact power requirement to the switch, which in turn enables smart budgeting of power to maximize the total number of UPOE devices that can be powered on a single line card.
How Is Power Budgeted to Individual Ports?
In addition to extending the power envelope defined by the IEEE 802.3 standard, UPOE also extends the LLDP-PoE dynamic power negotiation protocol defined by IEEE 802.3 to facilitate mutual identification and dynamic budgeting of power to individual ports. Additionally, UPOE also provides the users the capability to statically configure port power budget to enable devices that do not support the LLDP-PoE extensions for UPOE support.
How Does UPOE Tie in with Cisco’s Overall Enterprise Campus Access Strategy?
With the introduction of the Supervisor Engine 8-E, 7-E and 7L-E, the Cisco Catalyst 4500E has become Cisco’s leading modular campus access platform. The platform not only offers unprecedented switching bandwidth with line-rate switching to all user access ports and 10G uplinks but also has been the first platform to deliver next-generation services such as sub second ISSU, Flexible Netflow, Cisco TrustSec security, Wireshark as a hosted application, and medianet innovations. High availability and lower TCO continue to be the underlying goals for the platform. Cisco UPOE extends high availability for power while minimizing both CapEx and OpEx involved with power delivery.
More Cisco Network Topics:
Access control lists (ACLs) can be used for two purposes on Cisco devices: to filter traffic and to identify traffic.
Cisco provides basic traffic filtering capabilities with access control lists (also referred to as access lists). Access lists can be configured for all routed network protocols (IP, AppleTalk, and so on) to filter the packets of those protocols as the packets pass through a router.
You can configure access lists at your router to control access to a network: access lists can prevent certain traffic from entering or exiting a network.
Access lists filter network traffic by controlling whether routed packets are forwarded or blocked at the router's interfaces. Your router examines each packet to determine whether to forward or drop the packet, on the basis of the criteria you specified within the access lists.
Access list criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol, or other information.
Note that sophisticated users can sometimes successfully evade or fool basic access lists because no authentication is required.
Why do you need to configure Cisco ACLs? For example, you can use access lists to restrict contents of routing updates or to provide traffic flow control. One of the most important reasons to configure access lists is to provide security for your network.
You should use access lists to provide a basic level of security for accessing your network. If you do not configure access lists on your router, all packets passing through the router could be allowed onto all parts of your network.
Access lists can allow one host to access a part of your network and prevent another host from accessing the same area. In the follow-up figure, host A is allowed to access the Human Resources network, and host B is prevented from accessing the Human Resources network.
You can also use access lists to decide which types of traffic are forwarded or blocked at the router interfaces. For example, you can permit e-mail traffic to be routed, but at the same time block all Telnet traffic.
Access lists should be used in "firewall" routers, which are often positioned between your internal network and an external network such as the Internet. You can also use access lists on a router positioned between two parts of your network, to control traffic entering or exiting a specific part of your internal network.
To provide the security benefits of access lists, you should at a minimum configure access lists on border routers—routers situated at the edges of your networks. This provides a basic buffer from the outside network, or from a less controlled area of your own network into a more sensitive area of your network.
On these routers, you should configure access lists for each network protocol configured on the router interfaces. You can configure access lists so that inbound traffic or outbound traffic or both are filtered on an interface.
Access lists must be defined on a per-protocol basis. In other words, you should define access lists for every protocol enabled on an interface if you want to control traffic flow for that protocol.
Full Guide of Cisco Access Lists from http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html
Cisco Business Edition 6000 (BE 6000) is a packaged solution optimized for medium-sized business requirements. It is a combination of Cisco Unified Communications applications on the Cisco Unified Computing System (Cisco UCS) that offers midsize customers’ business agility and reduced TCO through server consolidation, operational efficiency and scalability, improved business continuity, and greater investment leverage.
Cisco BE 6000 consists of the following foundational elements:
You can optionally install the following applications to the BE 6000 solution:
In addition, Cisco BE 6000 integrates with cloud-based Cisco WebEx Software-as-a-Service offerings including WebEx Connect IM and Presence, as well as WebEx Web Conferencing.
Cisco BE 6000 comes with two hardware options of Cisco UCS 220 M3 Server:
What is the difference between Cisco Business Edition 6000 and generic unified communications applications on Cisco UCS ("UC on UCS")? The table will show you the Differences between Cisco BE 6000 and Deployments with Unified Communications Applications on Cisco UCS
Maximum Capacities of Cisco BE 6000
About Deployment Model-Cisco Business Edition 6000
Cisco BE 6000 supports fully featured redundancy for both LAN and WAN environments. You can deploy a redundant server for Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, and Cisco Unified Contact Center Express applications in a remote location over your WAN.
The Cisco BE 6000 Medium Density server supports up to five co-resident applications. However, the Cisco Virtualization Hypervisor software with license comes standard with Cisco BE 6000, and is entitled for two CPU sockets and 16 GB of virtual memory to deploy additional applications. Following are configuration scenario examples:
• Cisco BE6000 Medium Density server 1: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, Cisco Unified Contact Center Express, and Cisco Unified Provisioning Manager (primary)
• Cisco BE6000 Medium Density server 1: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, Cisco Unified Contact Center Express, and Cisco Unified Provisioning Manager (primary)
• Cisco BE6000 Medium Density server 1: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Contact Center Express, Cisco Unified Attendant Console, and Cisco Unified Provisioning Manager (primary)
Optional Cisco Virtualization Foundation Edition is entitled for two CPU sockets and 32 GB of virtual memory and enables the VMware vCenter compatibility feature.
Cisco Business Edition 6000 supports more than two nodes in the cluster. You can deploy Cisco BE 6000 with more than three nodes in the cluster as long as the user count does not exceed 1000 users.
Is Cisco Prime Collaboration Provisioning bundled with Business Edition 6000 different from the enterprise version of Cisco Prime Collaboration Provisioning? I have been using Cisco Unified Provisioning Manager Business Edition to manage Business Edition 6000. How do I migrate to the new management application Cisco Prime Collaboration Provisioning? Can I install Cisco Business Edition 6000 on a different specifications-based Cisco UCS Server or on a third-party server? Can I install any third-party application server on Cisco Business Edition 6000 hardware? Etc. More Qs about Cisco BE6000 and its licensing options you can read the full page Cisco Business Edition 6000 Q&A
In this article it describes the issue faced by a user on ASA 8.6.
Here the Problem is:
User is using ASA 5525 with 8.6 versions, and he is trying to ping through different interfaces, however he is not able to do that. The test results are mentioned below:
Can PING between the outside interface and the next hop (same subnet)
Cannot PING between the inside interface and the next hop (same subnet)
Cannot PING between the DMZ interface and the next hop (same subnet)
Please see below configuration for firewall for reference.
ip address 16.x.x.x 255.255.255.248
no ip address
ip address 17.x.x.x 255.255.255.0
no ip address
ip address 18.x.x.x 255.255.255.0
access-list o_inside extended permit icmp any any
access-list o_inside extended permit icmp any any echo
access-list o_inside extended permit icmp 17.x.x.x (Inside interface) 255.255.0.0 18.x.x.x (DMZ interface) 255.255.255.0
access-list o_inside extended permit icmp 17.x.x.x (Inside interface) 255.255.0.0 18.x.x.x (DMZ interface) 255.255.255.0
access-list o_dmz extended permit icmp any any
access-list outside extended permit icmp any any
access-list outside extended permit icmp any any echo-reply
icmp permit any outside
icmp permit any dmz
inspect icmp error
route inside 17.x.0.0 (Whole inside interface subnet) 255.255.0.0 17.x.x.x (Internal Network) 1
route dmz 17.x.x.0 (Internal) 255.255.255.0 18.x.x.x (DMZ Nework) 1
route outside 18.x.x.0 (DMZ) 255.255.255.0 16.x.x.x (Outside Network) 1
User wants to know what should be added to achive the above mentioned result.
ASA should by default without any configurations accept ICMP on its interface.
Check the output of "show arp" and see if you can see the IP address (and the MAC address) of the host/router you are trying to ping.
The 4 "static" configurations above are pretty basic but 2 of them are Static Identity NAT configurations that you probably won’t need in the new software
The below 2 configurations probably won’t need any corresponding configuration in the new ASA/software since the traffic should go through wihtout NAT configurations.
static (dmz,inside) 192.168.1.85 192.168.1.85 netmask 255.255.255.255
static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.255.0.0
The below Static NAT configurations you can easily convert using Auto NAT / Network Object NAT. Use "object" names that describe the setup better, use generic "object" names.
static (dmz,outside) 220.127.116.11 192.168.1.56 netmask 255.255.255.255
static (dmz,outside) 18.104.22.168 192.168.1.85 netmask 255.255.255.255
object network STATIC-1
nat (dmz,outside) static 22.214.171.124
object network STATIC-2
nat (dmz,outside) static 126.96.36.199
The best way to find possible problems with the ASA configurations is to use the "packet-tracer" command. This would tell you if some traffic is getting blocked by ACL or if the traffic is failing because of NAT
For a connection coming from behind "outside" you can use this format of the command
packet-tracer input outside tcp <source ip> 12345 <server nat ip> <destination port>
To test anything else you naturally just switch the "input <interface name>" to the one where the traffic is sourced from. You will naturally also have to check whether you need to use "tcp" or "udp" and also select a source/destination IP/port.
Taking the output of the following commands should help you to troubleshoot possible problems
You could take "packet-tracer" command output of both of the above mentioned cases. For example testing connectivity from "outside" to the "dmz" server. And the previous problem with testing connection from "inside" to "dmz" server.
If you are doing Dynamic PAT from "inside" to "dmz" then you should remove the above "static" commands that refer to "(inside,dmz)" then user wouldnt be able to connect from "dmz" to those "inside" IP addresses (of those static commands). This is the main reason why Dynamic PAT is not encouraged between local interfaces. It causes complexity for the NAT configurations when user have to add extra NAT configurations to override the possible problems caused by the Dynamic PAT
For the "management" interface you probably need any new NAT configuration.
The Dynamic PAT from "inside" to "dmz" means that you would need some Static Identity NAT configuration mentioned above also in the new software otherwise the ASA would drop the connection attempts.
nat (inside,dmz) after-auto source dynamic inside-pat-source dmz-pat-global
More Related Cisco ASA Topics:
Multiple vulnerabilities have been discovered in several Cisco products, including Cisco Adaptive Security Appliance (ASA) 5500 Series, Cisco Catalyst 6500 Series ASA and Firewall Services Module (FWSM), Cisco 7600 Series Routers ASA and FWSM, Cisco ASA 1000V Cloud Firewall, as well as Cisco 1000 Series Aggregation Services Routers (ASR) running Cisco IOS XE. These products provide firewall, intrusion prevention, remote access, and other services. Successful exploitation of these vulnerabilities could result in denial of service conditions or reboot of the affected device.
Cisco Adaptive Security Appliance (ASA) Software for:
- Cisco ASA 5500 Series Adaptive Security Appliances
- Cisco ASA Services Module for Cisco Catalyst 6500 Series Switches
- Cisco ASA Services Module for Cisco 7600 Series Routers
- Cisco ASA 1000V Cloud Firewall
Cisco Firewall Services Module (FWSM) Software for:
Cisco IOS XE Software for:
- Cisco 1000 Series Aggregation Services Routers (ASR)
- Small government entities: High
- Large and medium government entities: High
- Large and medium business entities: High
- Small business entities: High
Home users: N/A
Multiple Cisco products are vulnerable to a remote Denial of Service condition. The details of each vulnerable Cisco product are provided below.
Cisco Adaptive Security Appliance (ASA) 5500 Series, Cisco Catalyst 6500 Series ASA and Firewall Services Module (FWSM), Cisco 7600 Series Routers ASA and FWSM, Cisco ASA 1000V Cloud Firewall
To exploit these vulnerabilities, an attacker needs to create a specially crafted packet that will cause a denial of service condition when processed by the appliance. Affected versions of Cisco ASA and FWSM software will vary depending on the specific vulnerability.
The details of the vulnerabilities are as follows:
- Cisco ASA and Cisco FWSM are prone to a remote denial-of-service vulnerability because they fail to properly process an incoming IKE version 1 message. An attacker can exploit this vulnerability by sending a crafted IKE message, causing a reload of an affected device, denying service to legitimate users. Switching to IKE version 2 will mitigate this vulnerability. This issue is being tracked by Cisco Bug IDs CSCub85692 and CSCud20267 (CVE-2013-1149).
- Cisco FWSM for the Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers is prone to a denial-of-service vulnerability due to the incorrect processing of URLs. Specifically, this issue occurs when clients make requests through the auth-proxy feature. An attacker can exploit this issue to cause a vulnerable device to reload, triggering a denial-of-service condition. Disabling AAA for network access control and HTTP(S) listening ports to authenticate network users, if feasible, will mitigate this vulnerability. This issue is tracked by Cisco Bug ID CSCtg02624 (CVE-2013-1155).
- Cisco Adaptive Security Appliance (ASA) is prone to a remote denial-of-service vulnerability. Specifically, this issue occurs in the URL processing code of the authentication proxy feature. An attacker can exploit this vulnerability by sending a crafted URL, causing a reload of an affected device, denying service to legitimate users. This issue is being tracked by Cisco Bug ID CSCud16590 (CVE-2013-1150).
- Cisco Adaptive Security Appliance (ASA) is prone to a remote denial-of-service vulnerability due to an implementation error in the code that validates the digital certificates used during authentication. An attacker can exploit this issue by using a crafted certificate to trigger an authentication operation on an affected device, causing a reload of an affected device, denying service to legitimate users. This issue is being tracked by Cisco Bug ID CSCuc72408 (CVE-2013-1151)
- Cisco Adaptive Security Appliance (ASA) is prone to a remote denial-of-service vulnerability that occurs in the DNS inspection engine code. Specifically, this issue occurs because of improper processing of certain fields in DNS messages. An attacker can exploit this issue by sending a crafted DNS message, causing a reload of an affected device, denying service to legitimate users. Disabling DNS inspection, if feasible, will mitigate this vulnerability. This issue is being tracked by Cisco Bug ID CSCuc80080 (CVE-2013-1152).
Cisco IOS XE Software for Cisco 1000 Series Aggregation Services Router (ASR).
To exploit these vulnerabilities, an attacker needs to create a specially crafted packet that will cause a denial of service when processed by the software. Affected versions of Cisco IOS XE Software for 1000 Series ASR will vary depending on the specific vulnerability.
The details of the vulnerabilities are as follows:
- Improper handling of fragmented IPv6 multicast and IPv6 MVPN traffic by Cisco 1000 Series ASR with ASR1000-ESP40 or ASR1000-ESP100 may allow an attackers to cause a reload of the affected devices, denying service to legitimate users. This issue is being tracked by Cisco Bug IDs CSCtz97563 and CSCub34945 (CVE-2013-1164).
- Improper handling of specific L2TP packets by Cisco 1000 ASR may allow an attackers to cause a reload of the affected devices, denying service to legitimate users. Repeated attacks will result in a sustained denial of service. This issue is being tracked by Cisco Bug ID CSCtz23293 (CVE-2013-1165).
- Improper handling of packets by Cisco 1000 Series ASR configured for bridge domain interface (BDI) may allow attackers to cause a reload of the affected devices, denying service to legitimate users. Repeated attacks will result in a sustained denial of service. This issue is being tracked by Cisco Bug ID CSCtt11558 (CVE-2013-1167).
- Improper handling of a large number SIP packets by Cisco 1000 Series ASR when configured for VRF-aware NAT and SIP ALG may allow an attackers to cause a reload of the affected devices, denying service to legitimate users. Repeated attacks will result in a sustained denial of service. This issue is being tracked by Cisco Bug ID CSCuc65609 (CVE-2013-1166).
We recommend the following actions be taken:
- Upgrade vulnerable Cisco products immediately after appropriate testing.
- Consider migrating from IKE version 1 to IKE version 2.
For the ASA firewall, IPv6 feature support has been available and can be set up quickly. In this article it focuses on a basic ASA setup for a native IPv6 network. As you will see, there are very few commands required to have your ASA firewall join an IPv6 ready network.
Here is a quick way to configure up your ASA firewall for IPv6 connectivity.
STEP#1-Enable IPv6 on the interface and configure up the global IPv6 address.
interface vlan 2
ipv6 address 2001:db8:2:3::1/64
This will assign the IPv6 global address to the interface. When you enter IPv6 enable, a link local address is automatically generated (this is based on your mac address). With the IPv6 address command above, you are manually specifying the global, however the ASA also allows for autoconfig which will receive stateless configurations based on RA router advertisement messages.
For more details, you can review the following reference guide document:
STEP#2-Verify IPv6 configuration.
show ipv6 interface
outside is up, line protocol is up
IPv6 is enabled, link-local address is fe80::21e:7aff:fe11:45c
Global unicast address(es):
2001:db8:2:3::1, subnet is 2001:db8:2:3::/64
Joined group address(es):
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 1000 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses
STEP#3-Define an IPv6 default route.
ipv6 route outside ::/0 next_hop_ipv6_addr
Using ::/0 is equivelant to “any”. The IPv6 route command is functionally similar to the IPv4 route.
STEP#4-Define IPv6 access-lists (optional).
IPv6 access-lists are functionally the same as IPv4. They are parsed sequentially and have an implicit deny at the end.
ipv6 access-list test permit tcp any host 2001:db8::203:A0FF:FED6:162D
access-group test in interface outside
The above is permitting traffic to a specific server 2001:db8::203:A0FF:FED6:162D.
Securing the Firewall:
If you plan to configure auto-config for the IPv6 global address on the ASA, you should limit the amount of router advertisements (RA) to known routers in your network. This will help prevent the ASA from being auto configured from unknown routers.
ipv6 access-list outsideACL permit icmp6 host fe80::21e:7bff:fe10:10c any router-advertisement
ipv6 access-list outsideACL deny icmp6 any any router-advertisement
access-group outsideACL in interface outside
ipv6 address autoconfig
The above access-list when applied on the ASA will limit receiving router advertisements (RA) from only the router specified. All other RAs will be denied.
If you wish to prevent the ASA from sending out router advertisements (RA) on a specific interface, you may suppress them with the following interface command:
ipv6 nd suppress-ra
Neighbor discovery will continue to be operational even though RA suppression has been configured.
For further information, please check out the following documentation on cisco.com:
ASA 8.3 IPv6 configuration guide:
ASA 8.3 IPv6 command reference:
Reference from https://supportforums.cisco.com/docs/DOC-15973