PIX/ASA 7.x: Enable Communication Between Interfaces

network

PIX/ASA 7.x: Enable Communication Between Interfaces

Downloads PIX/ASA 7.x: Enable Communication Between Interfaces Document ID: 81815 Contents Introduction Prerequisites       Requirements       Components Used       Related Products       Conventions Background Information       NAT       Security Levels       ACL Configure       Network Diagram       Initial Configuration       DMZ to Inside       Internet to DMZ       Inside/DMZ to Internet       Same Security Level Communication Troubleshoot NetPro Discussion Forums - Featured Conversations Related Information Introduction This document provides a sample configuration for various forms of communication between interfaces on the ASA/PIX security appliance. Prerequisites Requirements Ensure that you meet these requirements before you attempt this configuration: IP addresses and default gateway assignment Physical network connectivity between devices Communication port # identified for the service implemented Components Used The information in this document is based on these software and hardware versions: Adaptive Security Appliance that runs software Version 7.x Windows 2003 Servers Windows XP workstations The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command. Related Products This configuration can also be used with these hardware and software versions: PIX 500 Series firewalls that run 7.x Conventions Refer to the Cisco Technical Tips Conventions for more information on document conventions. Background Information This document outlines the required steps to allow communication to flow between different interfaces. Forms of communication such as these are discussed: Communication from hosts that are located on the outside that require access to resource located in the DMZ Communication from hosts on the inside network that require access to resources located in the DMZ Communication from hosts on the inside and the DMZ network that require access to resources on the outside NAT In our example, we use Network Address Translation (NAT) and Port Address Translation (PAT) in our configuration. Address translation substitutes the real address (local) in a packet with a mapped address (global) that is routable on the destination network. NAT is comprised of two steps: the process in which a real address is translated into a mapped address and then the process to undo translation for the traffic that returns. There are two forms of address translation that we use in this configuration guide: Static and Dynamic. Dynamic translations allows each host to use a different address or port for each subsequent translation. Dynamic translations can be used when local hosts share or "hide behind" one or more common global addresses. In this mode, one local address cannot permanently reserve a global address for translation. Instead, address translation occurs on a many-to-one or many-to-many basis, and translation entries are created only as they are needed. As soon as a translation entry is free from use, it is deleted and made available to other local hosts. This type of translation is most useful for outbound connections, in which inside hosts are assigned a dynamic address or port number only as connections are made. There are two forms of Dynamic address translation: Dynamic NAT - Local addresses are translated into the next available global address in a pool. Translation occurs on a one-to-one basis, so it is possible to exhaust the pool of global addresses if a greater number of local hosts require translation at a given time. NAT Overload (PAT) - Local addresses are translated into a single global address; each connection is made unique when the next available high-order port number of the global address is assigned as the source of the connection. Translation occurs on a many-to-one basis because many local hosts share one common global address. Static translation creates a fixed translation of the real address(es) to mapped address(es). A static NAT configuration maps the same address for each connection by a host and is a persistent translation rule. Static address translations are used when an internal or local host needs to have the same global address for every connection. Address translation occurs on a one-to-one basis. Static translations can be defined for a single host or for all addresses contained in an IP subnet. The main difference between dynamic NAT and a range of addresses for static NAT is that static NAT allows a remote host to initiate a connection to a translated host (if there is an access list that allows it), while dynamic NAT does not. You also need an equal number of mapped addresses with static NAT. The security appliance translates an address when a NAT rule matches the traffic. If no NAT rule matches, processing for the packet continues. The exception is when you enable NAT control. NAT control requires that packets that traverse from a higher security interface (inside) to a lower security level (outside) match a NAT rule, or else processing for the packet stops. In order to view common configuration information, refer to the PIX/ASA 7.x NAT and PAT document. For a deeper understanding of how NAT works, refer to the How NAT works guide. Tip: Whenever you change the NAT configuration, it is recommended that you clear current NAT translations. You can clear the translation table with the clear xlate command. However, take caution when you do this since clearing the translation table disconnects all current connections that use translations. The alternative to clearing the translation table is to wait for current translations to time out, but this is not recommended because unexpected behavior can result as new connections are created with the new rules. Security Levels The Security-level value controls how hosts/devices on the different interfaces interact with each other. By default, hosts/devices connected to interfaces with higher-security levels can access hosts/devices connected to interface with lower-security levels. Hosts/devices connected to interfaces with lower-security interfaces cannot access hosts/devices connect to interfaces with higher-security interfaces without the permission of access lists. The security-level command is new to Version 7.0 and replaces the portion of the nameif command that assigned the security level for an interface. Two interfaces, "the inside" and "outside" interfaces, have default security levels, but these can be overridden with the security-level command. If you name an interface "inside," it is given a default security level of 100; an interface named "outside" is given a a default security level of 0. All other newly added interfaces receive a default security level of 0. In order to assign a new security level to an interface, use the security-level command in the interface command mode. Security levels range from 1-100. Note: Security-levels are used only to determine how the firewall inspects and handles traffic. For example, traffic that passes from a higher-security interface toward a lower one is forwarded with less stringent default policies than traffic that comes from a lower security interface toward a higher-security one. For more information on security-levels, refer to the ASA/PIX 7.x command reference guide. ASA/PIX 7.x also introduced the ability to configure multiple interfaces with the same level of security. For example, multiple interfaces connected to partners or other DMZs can all be given a security level of 50. By default, these same security interfaces cannot communicate with one another. In order to work around this, the same-security-traffic permit inter-interface command was introduced. This command allows for communication between interfaces of the same security level. For more information on same-security between interfaces, refer to the Command Reference guideConfiguring Interface Parameters, and see this example. ACL Access Control lists typically consist of multiple access control entries (ACE) organized internally by the Security Appliance in a linked list. ACEs describe a set of traffic such as that from a host or network and list an action to apply to that traffic, generally permit or deny. When a packet is subjected to access list control, the Cisco Security Appliance searches this linked list of ACEs in order to find one that matches the packet. The first ACE that matches the security appliance is the one that is applied to the packet. Once the match is found, the action in that ACE (permit or deny) is applied to the packet. Only one access list is permitted per interface, per direction. This means that you can only have one access list that applies to traffic inbound on an interface and one access list that applies to traffic outbound on an interface. Access lists that are not applied to interfaces, such as NAT ACLs, are unlimited. Note: By default, all access-lists have an implicit ACE at the end that denies all traffic, so all traffic that does not match any ACE that you enter in the access list matches the implicit deny at the end and is dropped. You must have at least one permit statement in an interface access list for traffic to flow. Without a permit statement, all traffic is denied. Note: Access list are implemented with the access-list and access-group commands. These commands are used instead of the conduit and outbound commands, which were used in earlier versions of PIX firewall software. For more information on ACLs, refer to Configuring IP Access List. Configure In this section, you are presented with the information to configure the features described in this document. Note: Use the Command Lookup Tool ([size=-1] registered customers only) to obtain more information on the commands used in this section. Network Diagram This document uses the this network setup: Initial Configuration This document uses these configurations: With this basic firewall configuration, there are currently no NAT/STATIC statements. There are no ACLs applied, so the implicit ACE of deny any any is currently used. Device Name 1 ASA-AIP-CLI(config)#show running-config                        ASA Version 7.2(2)                        !                        hostname ASA-AIP-CLI                        domain-name corp.com                        enable password WwXYvtKrnjXqGbu1 encrypted                        names                        !                        interface Ethernet0/0                        nameif Outside                        security-level 0                        ip address 172.22.1.163 255.255.255.0                        !                        interface Ethernet0/1                        nameif inside                        security-level 100                        ip address 172.20.1.1 255.255.255.0                        !                        interface Ethernet0/2                        nameif DMZ                        security-level 50                        ip address 192.168.1.1 255.255.255.0                        !                        interface Ethernet0/3                        nameif DMZ-2-testing                        security-level 50                        ip address 192.168.10.1 255.255.255.0                        !                        interface Management0/0                        shutdown                        no nameif                        no security-level                        no ip address                        !                        passwd 2KFQnbNIdI.2KYOU encrypted                        ftp mode passive                        dns server-group DefaultDNS                        domain-name corp.com                        pager lines 24                        mtu inside 1500                        mtu Outside 1500                        mtu DMZ 1500                        no failover                        icmp unreachable rate-limit 1 burst-size 1                        no asdm history enable                        arp timeout 14400                        nat-control                        route Outside 0.0.0.0 0.0.0.0 172.22.1.1 1                        timeout xlate 3:00:00                        timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02                        timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00                        timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00                        timeout uauth 0:05:00 absolute                        no snmp-server location                        no snmp-server contact                        snmp-server enable traps snmp authentication linkup linkdown coldstart                        telnet timeout 5                        ssh timeout 5                        console timeout 0                        !                        class-map inspection_default                        match default-inspection-traffic                        !                        !                        policy-map type inspect dns preset_dns_map                        parameters                        message-length maximum 512                        policy-map global_policy                        class inspection_default                        inspect dns preset_dns_map                        inspect ftp                        inspect h323 h225                        inspect h323 ras                        inspect netbios                        inspect rsh                        inspect rtsp                        inspect skinny                        inspect esmtp                        inspect sqlnet                        inspect sunrpc                        inspect tftp                        inspect sip                        inspect xdmcp                        !                        service-policy global_policy global                        prompt hostname context                        Cryptochecksum:4b2f54134e685d11b274ee159e5ed009                        : end                        ASA-AIP-CLI(config)#   DMZ to Inside In order to allow communication from the DMZ to internal network hosts, use these commands. In this example, a web server on the DMZ needs to access an AD and DNS server on the inside. Create a static NAT entry for the AD/DNS server on the DMZ. Static NAT creates a fixed translation of a real address to a mapped address. This mapped address is an address that DMZ hosts can use to access the server on the inside without the need to know the real address of the server. This command maps the DMZ address 192.168.2.20 to the real inside address 172.20.1.5. ASA-AIP-CLI(config)# static (inside,DMZ) 192.168.2.20 172.20.1.5 netmask 255.255.255.255 ACLs are required to allow an interface with a lower security-level to have access to a higher security level. In this example, we give the web server that sits on the DMZ (Security 50) access to the AD/DNS server on the inside (Security 100) with these specific service ports: DNS, Kerberos, and LDAP. ASA-AIP-CLI(config)# access-list DMZtoInside extended permit udp host 192.168.1.10 host 192.168.2.20 eq domain ASA-AIP-CLI(config)# access-list DMZtoInside extended permit tcp host 192.168.1.10 host 192.168.2.20 eq 88 ASA-AIP-CLI(config)# access-list DMZtoInside extended permit udp host 192.168.1.10 host 192.168.2.20 eq 389 Note: The ACLs permit access to the mapped address of the AD/DNS server that was created in this example and not the real internal address. In this step, you apply the ACL to the DMZ interface in the inbound direction with this command: ASA-AIP-CLI(config)# access-group DMZtoInside in interface DMZ Tip: Whenever you change the NAT configuration, it is recommended that you clear current NAT translations. You can clear the translation table with the clear xlate command. Exercise caution when you do this since clearing the translation table disconnects all current connections that use translations. The alternative to clearing the translation table is to wait for the current translations to time out, but this is not recommended because unexpected behavior can result as new connections are created with the new rules. Other common configurations include these: Mail Servers in the DMZ SSH Access inside and outside Allowed Remote Desktop sessions through PIX/ASA devices Other DNS solutions when used in the DMZ Internet to DMZ In order to allow communication from users on the Internet, or outside interface (Security 0), to a web server that is located in the DMZ (Security 50), use these commands: Create a static translation for the web server in the DMZ to the outside. Static NAT creates a fixed translation of a real address to a mapped address. This mapped address is an address that hosts on the Internet can use to access the web server on the DMZ without the need to know the real address of the server. This command maps the outside address 172.22.1.25 to the real DMZ address 192.168.1.10. ASA-AIP-CLI(config)# static (DMZ,Outside) 172.22.1.25 192.168.1.10 netmask 255.255.255.255 Create an ACL that allows users from the outside to access the web server through the mapped address. Note that the web server also hosts the FTP. ASA-AIP-CLI(config)# access-list OutsidetoDMZ extended permit tcp any host 172.22.1.25 eq www ASA-AIP-CLI(config)# access-list OutsidetoDMZ extended permit tcp any host 172.22.1.25 eq ftp The last step in this configuration is to apply the ACL to the outside interface for traffic in the inbound direction. ASA-AIP-CLI(config)# access-group OutsidetoDMZ in interface Outside Note: Remember, you can only apply one access list per interface, per direction. If you already have an inbound ACL applied to the outside interface, you cannot apply this example ACL to it. Instead add the ACEs in this example into the current ACL that is applied to the interface. Tip: Whenever you change the NAT configuration, it is recommended that you clear current NAT translations. You can clear the translation table with the clear xlate command. Exercise caution when you do this since clearing the translation table disconnects all current connections that use translations. The alternative to clearing the translation table is to wait for current translations to time out, but this is not recommended because unexpected behavior can result as new connections are created with the new rules. Inside/DMZ to Internet In this scenario, hosts located on the inside interface (Security 100) of the security appliance are provided with access to the Internet on the outside interface (Security 0). This is achieved with the PAT, or NAT overload, form of dynamic NAT. Unlike the other scenarios, an ACL is not required in this case because hosts on a high-security interface access hosts on a low-security interface. Specify the source(s) of the traffic that must be translated. Here NAT rule number 1 is defined, and all traffic from inside and DMZ hosts is allowed. ASA-AIP-CLI(config)# nat (inside) 1 172.20.1.0 255.255.255.0 ASA-AIP-CLI(config)# nat (inside) 1 192.168.1.0 255.255.255.0 Specify what address, address pool, or interface the NATed traffic must use when it accesses the outside interface. In this case, PAT is performed with the outside interface address. This is especially useful when the outside interface address is not known beforehand, such as in a DHCP configuration. Here, the global command is issued with the same NAT ID of 1, which ties it to the NAT rules of the same ID. ASA-AIP-CLI(config)# global (Outside) 1 interface Tip: Whenever you change the NAT configuration, it is recommended that you clear current NAT translations. You can clear the translation table with the clear xlate command. Exercise caution when you do this since clearing the translation table disconnects all current connections that use translations. The alternative to clearing the translation table is to wait for current translations to time out, but this is not recommended because unexpected behavior can result as new connections are created with the new rules. Same Security Level Communication The initial configuration shows that interfaces "DMZ" and "DMZ-2-testing" are configured with security level (50); by default, these two interfaces cannot talk. Here we allow these interfaces to talk with this command: ASA-AIP-CLI(config)# same-security-traffic permit inter-interface Troubleshoot This section provides information you can use to troubleshoot your configuration. Troubleshooting connections through the PIX and ASA NAT ConfigurationsVerify NAT and Troubleshooting NetPro Discussion Forums - Featured Conversations Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the most recent conversations available in this technology. NetPro Discussion Forums - Featured Conversations for Security Security: Intrusion Detection [Systems] IOS IDS question - Jun 27, 2007 IDS with tacacs - Jun 27, 2007 Blocking on a Router - Jun 27, 2007 Help with first time IPS configuration - Jun 27, 2007 MARS - devices not reporting - Jun 27, 2007 Block File in My Network - Apr 9, 2007 catalyst 4507 and IPS - Apr 9, 2007 CSA 4.5 -> 5.2 migration - Apr 9, 2007 CS-MARS Custom ISA Server Parser - Apr 9, 2007 Starting to be a JOKE!! - Apr 9, 2007 Security: AAA CSUtil failed - Jun 27, 2007 ACS Downloadable access list with PIX - Jun 27, 2007 Change the ACS home Page - Jun 27, 2007 device authorisation on ACS - Jun 27, 2007 Macintosh clients, 802.1x and NAC. - Jun 27, 2007 Mass-Change TACACS+ Key - Apr 9, 2007 Remote Console (ACS Pinout Diagram) - Apr 9, 2007 ADSL PPPoA...Brasil Telecom PVC 1/32 - Apr 9, 2007 AAA in CatOS cat4000.4-5-9.bin - Apr 9, 2007 QOS marking via AAA - Apr 8, 2007 Security: General ASA5510 SEC-BUN-K9 bundle - Jun 27, 2007 wireless WLC with NAC appliance - Jun 27, 2007 Is ACS required for the NAC Appliance? - Jun 27, 2007 NAC Appliance and Novell - Jun 27, 2007 ASA 5510 IOS version - Jun 27, 2007 Guest-Anchor-WLC and NAC integration guide - Apr 9, 2007 Disabled rule still triggering alerts? - Apr 9, 2007 Denying telnet traffic from VRF interfaces on the router - Apr 9, 2007 URL Redirect Feature when using L2 NAC with 802.1X - Apr 9, 2007 error message 106007 - Apr 9, 2007 Security: Firewalling Pix 501 port redirection and acl - Jun 27, 2007 Unexplained SNMP alert on 515e 6.3(5) - Jun 27, 2007 PIX 501 & 506 PDM Question - Jun 27, 2007 Need help with PAT translation - Jun 27, 2007 Fixup Protocol SMTP 25 - Jun 27, 2007 Pix 515E with a Game Server - Apr 9, 2007 PIx 515E Rule question - Apr 9, 2007 Best firewall for a cisco 3825 and cisco 4503 switch - Apr 9, 2007 ASA 5510 Basic Configuration Help - Apr 9, 2007 PIX 501 & 506E replacement - Apr 9, 2007 Related Information Cisco ASA Command Reference Cisco PIX Command Reference Cisco ASA Error and Systems Messages Cisco PIX Error and Systems Messages Technical Support & Documentation - Cisco Systems [size=-1] Updated: Mar 12, 2007 Document ID: 81815

Block File in My Network - Apr 9, 2007
catalyst 4507 and IPS - Apr 9, 2007
CSA 4.5 -> 5.2 migration - Apr 9, 2007
CS-MARS Custom ISA Server Parser - Apr 9, 2007
Starting to be a JOKE!! - Apr 9, 2007
Mass-Change TACACS+ Key - Apr 9, 2007
Remote Console (ACS Pinout Diagram) - Apr 9, 2007
ADSL PPPoA...Brasil Telecom PVC 1/32 - Apr 9, 2007
AAA in CatOS cat4000.4-5-9.bin - Apr 9, 2007
QOS marking via AAA - Apr 8, 2007
Guest-Anchor-WLC and NAC integration guide - Apr 9, 2007
Disabled rule still triggering alerts? - Apr 9, 2007
Denying telnet traffic from VRF interfaces on the router - Apr 9, 2007
URL Redirect Feature when using L2 NAC with 802.1X - Apr 9, 2007
error message 106007 - Apr 9, 2007
Pix 515E with a Game Server - Apr 9, 2007
PIx 515E Rule question - Apr 9, 2007
Best firewall for a cisco 3825 and cisco 4503 switch - Apr 9, 2007
ASA 5510 Basic Configuration Help - Apr 9, 2007
PIX 501 & 506E replacement - Apr 9, 2007