Un equipo no se autentica contra TACACS

Primero miramos si la clave SSH esta creada: show ip ssh show aaa session (para ver los usuarios conectados

Overview of the Firewall Services Module

Overview of the Firewall Services Module The Cisco Firewall Services Module (FWSM) for Cisco Catalyst 6500 series switches is a dedicated firewall solution that builds upon Cisco ASA (Adaptive Security Algorithm) stateful inspection technology. As already happened with the firewall functionality on ASA appliances, the FWSM also has Cisco PIX Firewall as its main ancestor. One natural consequence of that influence is the similarity that can be readily detected on the Command Line Interface (CLI) and configuration philosophy for all these three products. The FWSM is a specialized, firewall-only device. It can be combined though with other Catalyst 6500 services modules, such as the Application Control Engine (ACE) module, which enables a single chassis to provide additional services such as Server Load Balancing (SLB). The communication between the FWSM and the underlying Catalyst 6500 happens through the switch backplane. When using FWSM, any physical port on the switch can be enabled for firewall policies, saving time and efforts related to cabling. On the other hand, only those VLANs in the hosting chassis that have been explicitly assigned to the module will have access to FWSM services. This means that the switch can keep behaving as usual for the remaining VLANs. The FWSM is well suited for intranet Data Centers, where it can, for instance, control client access to the server-side VLANs. It also fits well for virtualized deployments, such as segmenting departments inside a company or offering firewall to customers, as an optional infrastructure service, within a service provider environment. One distinctive feature of the FWSM resides on its capability to run any combination of Transparent mode and Routed mode security contexts. ■ NP3 is frequently referred to as the Session Manager. It processes the first packet in a connection, counts established and incomplete connections, and creates translations. It is also in charge of performing TCP sequence number randomization . ■ NP1 and NP2 are called the Fast Path. These processors, among other tasks, are responsible for maintaining the connection table, performing per-packet session lookup, translating addresses (Network Address Translation [NAT] and Port Address Translation [PAT]), and reassembling fragments. ■ The Control Point (CP) corresponds to the main CPU: It handles traffic destined to or sourced from the FWSM, which basically corresponds to management (SNMP, SSH, Telnet, HTTPS, and so on) and control protocols (failover tasks, routing protocols, TACACS+, and so on). The CP also takes care of application protocol inspection (translating addresses embedded on the application layer, filtering application commands, and so on). The CP, the processor running the FWSM code, is often called the Slow Path.

Reflexive ACLs

A typical approach to network perimeter security is to allow outbound traffic not explicitly denied, and to deny inbound traffic unless it is explicitly allowed. Although simple in concept, this approach requires significant considerations regarding the return path of internally initiated sessions. Consider the following scenario:

Clients resides on the secure 192.168.0.0/24 subnet, which is connected to the Internet by Firewall. We can place both inbound and outbound access lists on Firewall F0/0 interface to restrict communication between our internal network and the Internet.

For the sake of an example, let's assume we want to allow web traffic from the client to web servers on the Internet. We can leave outbound traffic (from client to server) unrestricted by simply not including an ACL, but how would we restrict return traffic from the Internet? Obviously we can't simply deny all traffic, or nothing would work. Nor can we allow all traffic, as it would leave the secure subnet exposed.

We also can't simply allow all TCP traffic with a source port of 80, as an attacker could easily send malicious traffic using 80 as his source port. And we can't restrict inbound traffic to certain source IP addresses, as we'd have to create a new entry for every server we want to access on the Internet. We could allow inbound traffic to the client's source port, but this is typically a randomly-chosen high port number which can't be practically matched with static configuration. But what if we could record and match each source address/port pair automatically?

Enter reflexive access lists. To employ reflexive ACLs, three access lists are actually needed: one for inbound traffic, one for outbound traffic, and one (the reflexive ACL) to keep track of dynamic entries. Outbound traffic matched in the outbound ACL is reflected to the reflexive ACL; that is, the source and destination addresses and ports are swapped and the entry is recorded in the reflexive ACL with an expiration timer. Traffic in the other direction is matched against the inbound ACL, which in turn evaluates the entries in the reflexive ACL.

First let's create an outbound ACL named Egress to reflect entries for outgoing packets

Firewall(config)# ip access-list extended Egress
Firewall(config-ext-nacl)# permit ip any any reflect Mirror
Firewall(config-ext-nacl)# interface f0/0
Firewall(config-if)# ip access-group out Egress

Any packet matched by Egress will be reflected into our reflexive ACL,
named Mirror. Since Egress matches all IP traffic, we reflect entries
for TCP, UDP, and ICMP. If we wanted, we could have specified only TCP,
for example, to only match TCP traffic. While TCP sessions are
relatively simple to track, IOS can also roughly track UDP and ICMP
"sessions," even though these aren't true session-oriented protocols.

Now when a client in 192.168.0.0/24 initiates a TCP session to a server
on the Internet we can see a reflected entry is created in Mirror:



TRUSTED#ping 10.10.10.1 repeat 10000

Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!

FIREWALL#sh ip access-lists Mirror
Reflexive IP access list Mirror
 permit icmp host 10.10.10.1 host 192.168.0.2  (1273 matches) (time left 299)
FIREWALL#

Now, to put our reflexive ACL into action! We'll create an inbound ACL named Ingress to evaluate Mirror, and apply it inbound to FastEthernet0/0:

FIREWALL(config)# ip access-list extended Ingress
FIREWALL(config-ext-nacl)# evaluate Mirror
FIREWALL(config-ext-nacl)# interface f0/1
FIREWALL(config-if)# ip access-group in Ingress

Now packets inbound on FastEthernet0/0 are only allowed in if they are permitted by Ingress, which is essentially just a reference to Mirror. Note, however, that we are free to add normal entries to Ingress both before and after the evaluate statement if we want. With all three components in place, we can see the static outbound entries (Egress), the static inbound entries (Ingress), and the dynamic inbound entries (Mirror):

FIREWALL# sh ip access-lists
Extended IP access list Egress
10 permit ip any any reflect Mirror (61198 matches)
Extended IP access list Ingress
10 evaluate Mirror
Reflexive IP access list Mirror
permit icmp host 10.10.10.1 host 192.168.0.2 (2072 matches) (time left 299)


One last item to note is the expiration timer on the Mirror entry. This timer is reset to 300 seconds with each new packet that would cause the reflection. If no new traffic has been seen before the timer expires, the entry is erased. Additionally, when the router detects a session has been closed (for example, using the FIN flag in TCP), the timer is immediately reduced and the entry is removed shortly thereafter.

Enabling SSH on Cisco Device

Below shows the procedure for enabling SSH on a Cisco router:

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#crypto key generate rsa
% Please define a hostname other than Router.
Router(config)#hostname RT1
RT1(config)#crypto key generate rsa
% Please define a domain-name first.
RT1(config)#ip domain-name test.com
RT1(config)#crypto key generate rsa
The name for the keys will be: RT1.test.com
Choose the size of the key modulus in the range of 360 to 2048 for your
 General Purpose Keys. Choosing a key modulus greater than 512 may take
 a few minutes.

How many bits in the modulus [512]: 1024
Generating RSA keys ...
[OK]

RT1(config)#
00:00:37: %SSH-5-ENABLED: SSH 1.99 has been enabled
RT1(config)#^Z
RT1#
RT1#sh ip ssh
SSH Enabled - version 1.99
Authentication timeout: 120 secs; Authentication retries: 3
RT1#
RT1#sh ssh
%No SSHv2 server connections running.
%No SSHv1 server connections running.
RT1#
RT1#sh crypto key mypubkey rsa
% Key pair was generated at: 10:31:59 UTC Nov 20 2008
Key name: RT1.test.com
Usage: General Purpose Key
Key Data:
 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B357DC
 9A834E22 90813C9C 467F5347 4BB44A47 C4D988F5 9E5B304E DC5F49C0 D99615CF
 03D1A53B 084163BD 645AE36F 559D23C5 CB22846D EDE9C149 9837B6C7 BD98D546
 9329F7C9 4619ACE5 CD4B8884 C6630F03 6DDFE0D6 C24BE740 874A68D4 332FAF18
 A1DB3452 9A87BC2C 380E288D BA8E57F0 056225B9 7C9EE898 EDE73C22 C5020301 0001
% Key pair was generated at: 10:32:01 UTC Nov 20 2008
Key name: RT1.test.com.server
Usage: Encryption Key
Key Data:
 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00AE50E8 5BAE5D43
 A407A61F 8F6FCEF2 28A308B7 612B8375 0DD76815 3816538F F43D1D42 7927EC08
 FBDE6411 4C44BBC5 C4D39744 77D98109 FD0D8234 DDF5E75C FA51538C 327EA2A9
 29BB5D7D 47458336 24A78731 1FAA5570 03F7893A B7530A62 65020301 0001
RT1#
RT1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
RT1(config)#crypto key zeroize rsa
% Keys to be removed are named RT1.test.com.
Do you really want to remove these keys? [yes/no]: yes
RT1(config)#
00:03:12: %SSH-5-DISABLED: SSH 1.99 has been disabled
RT1(config)#^Z
RT1#
RT1#sh ip ssh
SSH Disabled - version 1.99
%Please create RSA keys to enable SSH.
RT1#
RT1#sh crypto key mypubkey rsa
RT1#

Advanced Access Control List Configurations

Dynamic access lists or Lock-and-Key Security is a type of ACL traffic filtering security feature that dynamically filters IP protocol traffic. Users that would like to traverse through the router are normally blocked by the extended ACL until they authenticates themselves to the router through a Telnet session with a username and password. After the user is authenticated, the Telnet connection is dropped, and a dynamic ACL entry is appended to the existing extended ACL to temporary allow the user to access resources that are blocked behind the router for certain duration until the specified timeout expires.

Below shows a sample Dynamic Access Lists configuration on RT1:

Router(config)#username remote password cisco123
Router(config)#username remote autocommand access-enable host timeout 10
Router(config)#access-list 101 permit tcp any host 172.16.0.1 eq telnet log
Router(config)#access-list 101 dynamic remote-access01 timeout 15 permit ip 172.16.0.0 0.0.0.255 10.10.10.0 0.0.0.255 log
Router(config)#int fa0/0
Router(config-if)#ip access-group 101 in
Router(config-if)#exit
Router(config)#line vty 0 4
Router(config-line)#login local

Note: Configuring the autocommand access-enable host timeout 10 line command under line vty 0 4 which is normally found in other configuration examples is not as flexible as configuring the autocommand for particular users with the username privileged commands.

Below describes the configuration steps for the sample dynamic access list configuration:
1) Create a user authentication method on the router. This can either be local authentication or remote security database using RADIUS or TACACS+ server. This sample configuration defines a user named remote with a password of cisco123 and a line of command (access-enable host timeout 10 in this case) which will be issued automatically (due to the autocommand keyword) after the user is authenticated via the Telnet session to the router.
Note: The access-enable EXEC command creates a temporary access-list entry.
2) Define an extended ACL to allow only Telnet access to the router (for authentication), but block all other traffic.
3) Create a dynamic extended ACL that applies to the extended access list 101 after the user is authenticated via the Telnet session to the router.
4) Since this sample configuration is using local authentication, the router needs to be configured to locally authenticate when a user connects to its VTY ports.

Reflexive access lists are dynamic access lists that allow traffic based on the detection of traffic in the opposite direction as well as upper-layer session information. They often permit outbound traffic which originated from an inside network but deny inbound traffic which originated from an outside network.

Reflexive ACLs cannot be defined with standard or numbered ACLs; they can only be defined with extended named ACLs and can be used along with other standard or extended ACLs. They are temporary entries that are created when a new IP session begins and are removed when the session ends (when the last segment with FIN or RST is seen or the idle timeout expires). Reflexive ACLs are not applied directly to an interface, but are “nested” within an extended named IP ACL that is applied to an interface.

Below shows a sample Reflexive Access Lists configuration on RT1 as well as the output of the show access-list EXEC command on RT1:

!
ip access-list extended Telnet-In
evaluate RACL-1
deny   ip any any
ip access-list extended Telnet-Out
permit tcp host 172.16.0.2 host 10.10.10.2 eq telnet reflect RACL-1
deny   ip any any
!
interface FastEthernet1/0
ip address 10.10.10.1 255.255.255.0
ip access-group Telnet-In in
ip access-group Telnet-Out out
!
----------------------------------------------------------------------------
RT1#sh access-list
Reflexive IP access list RACL-1
Extended IP access list Telnet-In
  10 evaluate RACL-1
  20 deny ip any any
Extended IP access list Telnet-Out
  10 permit tcp host 172.16.0.2 host 10.10.10.2 eq telnet reflect RACL-1
  20 deny ip any any
RT1#

Time-based access lists provide time-oriented access control. A certain time of day and week is specified and the period is often identified with a time range reference name. The time range name will be used as a reference in extended ACL configuration.

Below shows a sample Time-based Access Lists configuration that defines no Internet access during office hours – Monday to Friday, 9am to 6pm.

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#time-range no-http
Router(config-time-range)#?
Time range configuration commands:
absolute  absolute time and date
default   Set a command to its defaults
exit      Exit from time-range configuration mode
no        Negate a command or set its defaults
periodic  periodic time and date

Router(config-time-range)#periodic ?
Friday     Friday
Monday     Monday
Saturday   Saturday
Sunday     Sunday
Thursday   Thursday
Tuesday    Tuesday
Wednesday  Wednesday
daily      Every day of the week
weekdays   Monday thru Friday
weekend    Saturday and Sunday

Router(config-time-range)#periodic weekdays 09:00 to 18:00
Router(config-time-range)#exit
Router(config)#ip access-list extended Time_no-http
Router(config-ext-nacl)#deny tcp any any eq www time-range no-http
Router(config-ext-nacl)#permit tcp any any
Router(config-ext-nacl)#exit
Router(config)#int fa0/0
Router(config-if)#ip access-group Time_no-http in
Router(config-if)#^Z
Router#
Router#sh clock
10:00:01.835 UTC Sun Jan 6 2008
Router#sh time-range
time-range entry: no-http (inactive)
 periodic weekdays 9:00 to 18:00
 used in: IP ACL entry
Router#sh access-list
Extended IP access list Time_no-http
  deny tcp any any eq www time-range no-http (inactive)
  permit tcp any any
Router#
----------------------------------------------------------------------------
Router#sh clock
10:00:01.139 UTC Mon Jan 7 2008
Router#sh time-range
time-range entry: no-http (active)
 periodic weekdays 9:00 to 18:00
 used in: IP ACL entry
Router#sh access-list
Extended IP access list Time_no-http
  deny tcp any any eq www time-range no-http (active)
  permit tcp any any
Router#

Context-Based Access Control (CBAC) is a Cisco IOS Firewall feature which provides advanced traffic filtering functionality and secure access control on a per-application basis. CBAC is often referred to as Stateful IOS Firewall Inspection.

CBAC provides multiple levels of network protection with the following functions:

Traffic Filtering	Intelligently filters TCP and UDP segments based on application layer protocol information (eg: FTP connection information). Without CBAC, traffic filtering is limited to access list implementations which only able to examine the information at the network and transport layers. Due to the capability of learning the state information of the sessions and control them, CBAC supports filtering for application layer protocols that involve multiple channels created as a result of negotiations in the control channel. Many multimedia protocols and other protocols (eg: FTP, RPC, SQL*Net) involve multiple channels in their communications. CBAC can be configured to inspect application layer traffic for sessions and connections that are originated from either side of a firewall and permit the specified traffic through it; hence it can be used for intranet, extranet, and Internet perimeters of a network.
Traffic Inspection	Inspects traffic that passes through a firewall to discover and manage state information for TCP and UDP sessions. The state information is used to create temporary openings in the access lists to allow return traffic for permissible sessions. With the capabilities of inspecting and maintaining TCP and UDP session information, CBAC is able to detect and prevent certain types of network attacks, eg: SYN Flooding. CBAC helps to protect against DoS attacks with the following approaches: i) Inspects TCP sequence numbers in to see if they are within expected ranges and drops the suspicious packets. ii) Drops half-open connections, which require firewall processing and memory resources to maintain. iii) Detects unusually high rates of new connections and issue alert messages. Besides that, CBAC can also help to protect against certain DoS attacks which involve fragmented IP packets. Even though the firewall prevents an attacker from establishing actual connections to an end system, the attacker can disrupt services on the end system by sending many non-initial IP fragments, which can eventually tie up resources on the target end system as it tries to reassemble the incomplete packets.
Alerts and Audit Trails	Generates real-time alerts and audit trails for tracking suspicious activities and network transactions (eg: time stamps, source and destination hosts, ports, total number of transmitted bytes, etc). With CBAC inspection rules, alerts and audit trail information can be configured on a per-application protocol basis.
Intrusion Prevention	Provides a limited amount of intrusion detection to protect against specific SMTP attacks. With intrusion detection, SYSLOG messages are reviewed and monitored for specific attack signatures. When CBAC detects an attack, it resets the offending connections and generates a SYSLOG message to a SYSLOG server.

CBAC only effective for the specified protocols. If a particular is not specified for CBAC, the existing access lists will determine how the traffic for the particular protocol is being processed. No temporary openings will be created for protocols that are not specified for CBAC inspection.

CBAC can only provide protection against certain types of attacks, but not all types of attacks. CBAC should not be considered as a perfect defense; there is no such thing as a perfect defense. CBAC detects and prevents most types of popular network attacks.

Authentication Proxy requires the Cisco IOS Firewall feature set as well. It is able to authenticate inbound and/or outbound users and grant the access to the resources that are blocked behind a firewall. By launching a browser to access resources behind the firewall, the firewall would respond to the HTTP session and redirect the user to an authentication page which a valid username and password must be supplied for authentication purpose. An authentication entry will be created for the user. There is no intervention by the authentication proxy for subsequent HTTP sessions through the firewall as long as a valid authentication entry exists for the user.

The Access Control List 'fragments' Keyword

The fragments keyword indicates that an access list entry is only applied to non-initial packet fragments (L3). The fragment is either permitted or denied accordingly. The default behavior is without the fragments keyword.

The fragments keyword cannot be configured for an access list entry that contains any L4 information. Ex: access-list 101 permit tcp host 1.1.1.1 host 2.2.2.2 eq 80 fragments is invalid.

Without the fragments keyword (default), an access list entry that contains only L3 information (eg: access-list 101 permit ip host 10.10.10.1 host 10.10.10.2) is matched with all types of packets – non-fragmented packets, initial and non-initial packet fragments.
Note: The fragments keyword indicates that an access list entry will be matched with non-initial fragments.

Without the fragments keyword (default), an access list entry that contains L3 and L4 information (eg: access-list 101 permit tcp host 10.10.10.1 host 10.10.10.2 eq telnet) is matched with non-fragmented packets and initial packet fragments and is either permitted or denied accordingly.

• When a permit statement (without the fragments keyword) is matched with non-initial packet fragments, the non-initial fragments are permitted.
  
• When a deny statement (without the fragments keyword) is matched with non-initial packet fragments, the next access list entry is processed, and the fragments are not being denied!
  

Summary: The deny statements (without the fragments keyword) are handled differently for non-initial packet fragments than the permit statements (without the fragments keyword).

Do not simply add the fragments keyword to every access list entry, as the 1st fragment (initial fragment) will not be matched with an access list permit or deny entry that contains the fragments keyword – the packet is compared to the next access list entry, until it is either permitted or denied by an access list entry that does not contain the fragments keyword. Therefore, 2 deny access list entries are needed for every deny entry. The 1st deny entry of the pair will not include the fragments keyword to be applied for initial fragments; the 2nd deny entry of the pair will include the fragments keyword to be applied for non-initial fragments.

Note: Packet fragments are considered individual packets and each is counted individually as a packet in access list accounting.

When there are multiple deny access list entries for a particular host with different L4 ports, only a single deny access list entry with the fragments keyword for the host is required. All the packet fragments are handled in the same manner by the access list.

The fragment control feature affect policy routing if the policy routing is based on the match ip address command and the access list has entries that match L4 through L7 information. It is possible for non-initial fragments to be matched with the access list and are policy routed, even if the 1st fragment was not policy routed (or the reverse).

This feature provides a better match capability between initial and non-initial fragments and hence allows the configuration of advanced policy routing.

Switch Port Access Control Lists

Switch port ACLs can only be applied as inbound lists with extended named access lists upon L2 switch interfaces.

MAC extended access lists perform filtering based on the source and destination MAC addresses, as well as the optional EtherType information.

Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#mac access-list ?
extended  Extended Access List

Switch(config)#mac access-list extended ?
WORD  access-list name

Switch(config)#mac access-list extended example01
Switch(config-ext-macl)#deny any host ?
H.H.H  48-bit destination MAC address

Switch(config-ext-macl)#deny any host 1111.1111.1111
Switch(config-ext-macl)#permit any any
Switch(config-ext-macl)#^Z
Switch#
Switch#sh access-list
Extended MAC access list example01
 deny   any host 1111.1111.1111
 permit any any
Switch#
Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#int fa0/1
Switch(config-if)#mac access-group example01 ?
in  Apply to Ingress

Switch(config-if)#mac access-group example01 in
Switch(config-if)#^Z
Switch#
Switch#sh mac access-group int fa0/1
Interface FastEthernet0/1:
Inbound access-list is example01
Switch#

The question is do we really want to deny MAC addresses? Deny access based on the EtherType field in the Ethernet frame header is usually the better option.

Blocking 0x0800 would mean blocking all IP traffic, which could be handy in the future when forcing everyone to run IPv6!

MAC access lists can filter traffic based on various EtherType:

Switch(config-ext-macl)#deny any any ?
<0-65535>     An arbitrary EtherType in decimal, hex, or octal
aarp          EtherType: AppleTalk ARP
amber         EtherType: DEC-Amber
appletalk     EtherType: AppleTalk/EtherTalk
cos           CoS value
dec-spanning  EtherType: DEC-Spanning-Tree
decnet-iv     EtherType: DECnet Phase IV
diagnostic    EtherType: DEC-Diagnostic
dsm           EtherType: DEC-DSM
etype-6000    EtherType: 0x6000
etype-8042    EtherType: 0x8042
lat           EtherType: DEC-LAT
lavc-sca      EtherType: DEC-LAVC-SCA
lsap          LSAP value
mop-console   EtherType: DEC-MOP Remote Console
mop-dump      EtherType: DEC-MOP Dump
msdos         EtherType: DEC-MSDOS
mumps         EtherType: DEC-MUMPS
netbios       EtherType: DEC-NETBIOS
vines-echo    EtherType: VINES Echo
vines-ip      EtherType: VINES IP
xns-idp       EtherType: XNS IDP

Fun with NATs and ACLs (Firewalls)

Network Setup for NATs and ACLs

NAT configuration on RT1 for PC1 to remote access PC2 192.168.1.2 via NAT IP 172.16.1.3:
RT1(config)#ip nat inside source static 192.168.1.2 172.16.1.3

NAT configuration on RT2 for PC2 to remote access PC1 172.16.1.2 via NAT IP 192.168.1.3:
RT2(config)#ip nat inside source static tcp 172.16.1.2 23 192.168.1.3 23

Extended IP Access Lists configuration on RT1 and RT2 for PC1 to remote access (Telnet) PC2:

PC1 to PC2:
RT1(config)#access-list 101 permit tcp host 172.16.1.2 host 172.16.1.3 eq 23
RT2(config)#access-list 103 permit tcp host 172.16.1.2 host 192.168.1.2 eq 23

PC2 back to PC1:
RT2(config)#access-list 104 permit tcp host 192.168.1.2 eq 23 host 192.168.1.3
RT1(config)#access-list 102 permit tcp host 192.168.1.2 eq 23 host 172.16.1.2

Extended IP Access Lists configuration on RT1 and RT2 for PC2 to remote access (Telnet) PC1:

PC2 to PC1:
RT2(config)#access-list 104 permit tcp host 192.168.1.2 host 192.168.1.3 eq 23
RT1(config)#access-list 102 permit tcp host 192.168.1.2 host 172.16.1.2 eq 23

PC1 back to PC2:
RT1(config)#access-list 101 permit tcp host 172.16.1.2 eq 23 host 172.16.1.3
RT2(config)#access-list 103 permit tcp host 172.16.1.2 eq 23 host 192.168.1.2

Below shows the NAT operations on RT1 and RT2 and ACL hit counts when PC1 accesses PC2:

RT1#debug ip nat
IP NAT debugging is on
RT1#
00:02:30: NAT: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [14748]
00:02:32: NAT: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [14748]
00:02:36: NAT: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [14748]
00:02:38: NAT*: s=192.168.1.2->172.16.1.3, d=172.16.1.2 [19343]
00:02:38: NAT*: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [14749]
00:02:38: NAT*: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [14750]
--- output omitted ---
RT1#
RT1#sh access-list
Extended IP access list 101
  10 permit tcp host 172.16.1.2 host 172.16.1.3 eq telnet (28 matches)
  20 permit tcp host 172.16.1.2 eq telnet host 172.16.1.3
Extended IP access list 102
  10 permit tcp host 192.168.1.2 eq telnet host 172.16.1.2 (14 matches)
  20 permit tcp host 192.168.1.2 host 172.16.1.2 eq telnet
RT1#
RT1#sh ip nat statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Outside interfaces:
FastEthernet0/0
Inside interfaces:
FastEthernet1/0
Hits: 36  Misses: 0
Expired translations: 0
Dynamic mappings:
RT1#
----------------------------------------------------------------------
RT2#
00:02:31: NAT: s=172.16.1.2->192.168.1.3, d=192.168.1.2 [14748]
00:02:37: NAT*: s=192.168.1.2, d=192.168.1.3->172.16.1.2 [19343]
00:02:37: NAT*: s=172.16.1.2->192.168.1.3, d=192.168.1.2 [14749]
--- output omitted ---
RT2#sh access-list
Extended IP access list 103
  10 permit tcp host 172.16.1.2 host 192.168.1.2 eq telnet (25 matches)
  20 permit tcp host 172.16.1.2 eq telnet host 192.168.1.2
Extended IP access list 104
  10 permit tcp host 192.168.1.2 eq telnet host 192.168.1.3 (14 matches)
  20 permit tcp host 192.168.1.2 host 192.168.1.3 eq telnet
RT2#
----------------------------------------------------------------------
PC1#telnet 172.16.1.3
Trying 172.16.1.3 ... Open


User Access Verification

Password:
PC2>who
  Line       User       Host(s)              Idle       Location
 0 con 0                idle                 00:00:56
* 66 vty 0                idle                 00:00:00 192.168.1.3

Interface    User               Mode         Idle     Peer Address

PC2>

Below shows the NAT operations on RT2 and RT1 and ACL hit counts when PC2 accesses PC1:

RT2#debug ip nat
IP NAT debugging is on
RT2#
00:04:42: NAT: s=192.168.1.2, d=192.168.1.3->172.16.1.2 [50878]
00:04:42: NAT*: s=172.16.1.2->192.168.1.3, d=192.168.1.2 [2634]
00:04:42: NAT*: s=192.168.1.2, d=192.168.1.3->172.16.1.2 [50879]
00:04:42: NAT*: s=192.168.1.2, d=192.168.1.3->172.16.1.2 [50880]
--- output omitted ---
RT2#
RT2#sh access-list
Extended IP access list 103
  10 permit tcp host 172.16.1.2 host 192.168.1.2 eq telnet
  20 permit tcp host 172.16.1.2 eq telnet host 192.168.1.2 (17 matches)
Extended IP access list 104
  10 permit tcp host 192.168.1.2 eq telnet host 192.168.1.3
  20 permit tcp host 192.168.1.2 host 192.168.1.3 eq telnet (25 matches)
RT2#
RT2#sh ip nat statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Outside interfaces:
FastEthernet0/0
Inside interfaces:
FastEthernet1/0
Hits: 40  Misses: 0
Expired translations: 0
Dynamic mappings:
RT2#
----------------------------------------------------------------------
RT1#
00:04:43: NAT: s=192.168.1.2->172.16.1.3, d=172.16.1.2 [50878]
00:04:43: NAT*: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [2634]
00:04:43: NAT*: s=192.168.1.2->172.16.1.3, d=172.16.1.2 [50879]
00:04:43: NAT*: s=172.16.1.2, d=172.16.1.3->192.168.1.2 [2635]
--- output omitted ---
RT1#sh access-list
Extended IP access list 101
  10 permit tcp host 172.16.1.2 host 172.16.1.3 eq telnet
  20 permit tcp host 172.16.1.2 eq telnet host 172.16.1.3 (17 matches)
Extended IP access list 102
  10 permit tcp host 192.168.1.2 eq telnet host 172.16.1.2
  20 permit tcp host 192.168.1.2 host 172.16.1.2 eq telnet (25 matches)
RT1#
----------------------------------------------------------------------
PC2#telnet 192.168.1.3
Trying 192.168.1.3 ... Open


User Access Verification

Password:
PC1>
PC1>who
  Line       User       Host(s)              Idle       Location
 0 con 0                idle                 00:00:35
* 66 vty 0                idle                 00:00:00 172.16.1.3

Interface    User               Mode         Idle     Peer Address

PC1>

Bidirectional (2-Way) NAT

Traditional Outbound NAT is designed to handle outbound connections, in which clients of the inside local network initiate requests to outside global Internet hosts. Bidirectional NAT, 2-Way NAT, or Inbound NAT is an enhancement upon NAT to handle connections initiated from the outside network.

The network setup on the figure above can be achieved using a single router. PC1 accesses PC2 using 172.16.1.3 outside local; while PC2 accesses PC1 using 192.168.1.3 inside global.

Bidirectional NAT configuration on RT1:

!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
ip nat inside
!
interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0
ip nat outside
!
ip nat inside source static 172.16.1.2 192.168.1.3
ip nat outside source static 192.168.1.2 172.16.1.3 add-route
!

The add-route keyword adds a static /32 host route for the outside local address. This route is used for routing and translating packets that travel from the inside to the outside of the network.

RT1#sh ip route

Gateway of last resort is not set

  172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.1.0/24 is directly connected, FastEthernet0/0
S       172.16.1.3/32 [1/0] via 192.168.1.2
C    192.168.1.0/24 is directly connected, FastEthernet1/0
RT1#