Ticket #09

Ticket #09

Network diagram

The problem:

R1 can't telnet R3. Fix the problem without compromising security.

The solution:

First, lets try to telnet to R3 from R1.

On R3:

R1#telnet 5.13.23.3
Trying 5.13.23.3 ... 
% Connection timed out; remote host not responding

Indeed, R1 can't telnet to R3.


Can R1 ping to R3?

On R1:

R1#ping 5.13.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.13.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/16 ms

R1 can reach R3. Which means we have a two way connectivity between R1 and R3 through R2.


Lets check if R3 filters R1.

On R3:

R3#sh ip access-list

R3#

There are no access-lists configured on R3, which means that R3 is not filtering any packets sourced from R3, but maybe R3 is filtering telnet using COPP?

On R3:

R3#sh run | i sec policy
R3#

No trace of any policy-map configuration.


Maybe R2 is filtering. Lets check it out.

On R2:

R2#sh ip access-lists 
Extended IP access list 101
    10 permit ip any host 5.13.12.1
    20 permit icmp any any (15 matches)

We do see an ACL configured on R2 with a reference to R1's F0/0 IP address. Lets see where its applied.

On R2:

R2#sh ip interface | i line protocol|access l
FastEthernet0/0 is up, line protocol is up
  Outgoing access list is not set
  Inbound  access list is 101
FastEthernet0/1 is up, line protocol is up
  Outgoing access list is not set
  Inbound  access list is not set
Serial1/0 is administratively down, line protocol is down
Serial1/1 is administratively down, line protocol is down
Serial1/2 is administratively down, line protocol is down
Serial1/3 is administratively down, line protocol is down
NVI0 is up, line protocol is up
  Outgoing access list is not set
  Inbound  access list is not set
SSLVPN-VIF0 is up, line protocol is up
  Outgoing access list is not set
  Inbound  access list is not set

We can see that the ACL is applied on the interface facing R3, F0/0.


Looking back at the ACL, it looks like it should permit traffic to R1's F0/0 interface, which is the interface which the telnet session is originated from, then what is the problem?


Since its an inbound ACL, lets enable TCP debugging on R3, to see if R1 is reaching R3 at all.

On R3:

R3#debug ip tcp transactions
TCP special event debugging is on
R3#
*Feb  2 13:51:34.454: Reserved port 0 in Transport Port Agent for TCP IP type 0
*Feb  2 13:51:34.458: TCP0: state was LISTEN -> SYNRCVD [23 -> 5.13.23.1(43542)]
*Feb  2 13:51:34.462: TCP: tcb 6831A188 connection to 5.13.23.1:43542, peer MSS 536, MSS is 516
*Feb  2 13:51:34.466: TCP: sending SYN, seq 225256152, ack 2476872741
*Feb  2 13:51:34.466: TCP0: Connection to 5.13.23.1:43542, advertising MSS 536
*Feb  2 13:51:34.486: TCP0: ICMP destination unreachable received
*Feb  2 13:51:34.490: TCP0: state was SYNRCVD -> CLOSED [23 -> 5.13.23.1(43542)]
*Feb  2 13:51:34.494: tcp0: T CLOSED 5.13.23.1:43542 5.13.23.3:23 early close
*Feb  2 13:51:34.494: TCB 0x6831A188 destroyed
R3#
*Feb  2 13:51:36.454: Reserved port 0 in Transport Port Agent for TCP IP type 0
*Feb  2 13:51:36.458: TCP0: state was LISTEN -> SYNRCVD [23 -> 5.13.23.1(43542)]
*Feb  2 13:51:36.458: TCP: tcb 683192D0 connection to 5.13.23.1:43542, peer MSS 536, MSS is 516
*Feb  2 13:51:36.466: TCP: sending SYN, seq 1883666081, ack 2476872741
*Feb  2 13:51:36.466: TCP0: Connection to 5.13.23.1:43542, advertising MSS 536
*Feb  2 13:51:36.470: TCP0: ICMP destination unreachable received
*Feb  2 13:51:36.470: TCP0: state was SYNRCVD -> CLOSED [23 -> 5.13.23.1(43542)]
*Feb  2 13:51:36.470: tcp0: T CLOSED 5.13.23.1:43542 5.13.23.3:23 early close
*Feb  2 13:51:36.470: TCB 0x683192D0 destroyed

We can notice the the SYS was received from 5.13.23.1 and not from 5.13.12.1, which is R1's F0/0 IP address! We might have NAT configured some where. The best NAT candidate is R2.


Lets have a look at R2's NAT translations.

On R2:

R2#sh ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
--- 5.13.23.1          5.13.12.1          ---                ---

Indeed, R2 translates R1's F0/0 IP address from 5.13.12.1 to 5.13.23.1, and this should change the way we look at ACL filtering traffic from R3. Lets have another look at the ACL, by enabling logging for dropped packets and trying to telnet again.

On R2:

R2(config)#access-list 101 deny ip any any log
R2(config)#
*Feb  2 16:41:48.258: %SEC-6-IPACCESSLOGP: list 101 denied tcp 5.13.23.3(0) -> 5.13.23.1(0), 1 packet  

We can see that the ACL has denied the returning telnet packet from R3 to R2's global IP address. The ACL is not looking at the inside IP address of R1's F0/0 interface. 


So, as we can see, inbound ACL is checked before NAT when going from the outside to the inside. This is documented on http://tinyurl.com/8vrj. But the configured ACL is allowing traffic to the inside IP address of R1. Lets fix the ACL to allow traffic from R3 to the R1's F0/0 global IP address and try to telnet again from R1 to R3.

On R2:

R2(config)#no access-list 101
R2(config)#access-list 101 permit ip any host 5.13.23.1
R2(config)#access-list 101 permit icmp any any

On R1:

R1#telnet 5.13.23.3
Trying 5.13.23.3 ...
% Connection timed out; remote host not responding

R1#telnet 5.13.23.3
Trying 5.13.23.3 ... Open

R3>

Success! 

                                          __ 
.-----.--.--.----.----.-----.-----.-----.|  |
|__ --|  |  |  __|  __|  -__|__ --|__ --||__|
|_____|_____|____|____|_____|_____|_____||__|