cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3369
Views
8
Helpful
9
Replies

Telnet restriction & IP address

hclisschennai
Level 1
Level 1

Hi Everybody

I have configured the router to restrict telnet & ssh access using access-class. Generally i user standard ACL. For testing i have configured extended ACL as below. Note: The router serial IP address is 172.24.1.1 (WAN IP) & 218.248.17.1 (LAN IP). I am trying to use 218.248.17.1 to telnet to Router

access-list 123 permit tcp any host 218.248.17.1 eq ssh

access-list 123 permit tcp host 218.248.17.2 host 218.248.17.1 eq telnet

access-list 123 deny any any log

line vty 0 15

access-class 123 in

transport input telnet ssh

When i do like this I am not able to telnet or SSH. I have the log as below

00:14:30.927: %SEC-6-IPACCESSLOGP: list 123 denied tcp 172.24.1.2(16412)

-> 0.0.0.0(23), 1 packet

Why it is showing 0.0.0.0 (23). What is the IP address the router selects for telnet / ssh traffic

When I change the ACL as below it works fine.

access-list 123 permit tcp any any eq ssh

access-list 123 permit tcp host 218.248.17.2 any eq telnet

access-list 123 deny any any log

Why this behaves like this.

Thanks in advance

RBK

1 Accepted Solution

Accepted Solutions

Here's what I would do:

For the LAN users (218.248.17.x), I would create an acl that would allow them only telnet, and then allow everyone else ssh:

Try your acl like this:

deny tcp 218.248.17.0 0.0.0.255 any eq 22

permit tcp 218.248.17.0 0.0.0.255 any eq 23

permit tcp any any eq 22

deny ip any any

This will deny any of your local users access to the routers via ssh, and they would have to use telnet. You would allow everyone else access into the router with SSH, but it would deny telnet (deny ip any any).

Apply it inbound on the line:

line vty 0 4

access-class TELNET in

transport input telnet ssh

You can tie this acl down even further by specifying just the hosts you're giving access to also. (Right now, the acl allows any host on your LAN access to the router.)

HTH,

John

HTH, John *** Please rate all useful posts ***

View solution in original post

9 Replies 9

John Blakley
VIP Alumni
VIP Alumni

You can try to change the source interface for telnet and ssh:

ip telnet source-interface fa0/1 <- whatever the 218.x.x.x address is on.

You can also change your ssh source interface also:

ip ssh source-interface fa0/1

What side of the link are you telnetting from? LAN or WAN side? I've used extended ACLs before, but haven't had this type of problem in the past. I'm going to try to configure this to see if what I gave you above works.

*Edit* - I can't get it to work either :) You would need to allow the host that you're telnetting from into any:

permit tcp host any eq 23

The above works, but I would be curious as to why the address (even telnetting to the egress interface) shows 0.0.0.0 and not the actual address of the router.

HTH,

John

HTH, John *** Please rate all useful posts ***

Richard Burts
Hall of Fame
Hall of Fame

RBK

In general it is better to use standard access lists rather than extended access lists for access-class and you are encountering some of the reasons that I say this.

Your extended access list for access-class will work only if you make the destination address "any".

One of the advantages of using access-class on the vty rather than using access-group on interfaces is that access-class will check any remote access attempt to the device and is not dependent on what the destination address was (no matter which interface the request was received on). The implication of this is that in checking traffic against the access list the access-class is not checking the destination address, so in your access list it must be any to work.

HTH

Rick

HTH

Rick

Update to my last post. If you change the direction of your access-class, it should work:

line vty 0 4

access-list WHATEVER out

One word of note though: If you do the above, you're telling the router that your inside (LAN) interface can be accessed from any host if you leave the access list the way that it is. You may want to try to lock that down a little further by doing what Rick suggested in the previous post about using a standard acl.

HTH,

John

HTH, John *** Please rate all useful posts ***

John

I am confused by this post. If you change the direction of the access-class from in to out, then you are no longer controlling who can get remote access to the router and are controlling where the router can telnet or SSH TO.

As I tried to explain in my post, the reason that the debug shows the destination address as 0.0.0.0 is that the process using the access list to evaluate attempts at remote access is not evaluating access to a specific destination address. So if your access list specifies the destination address as a specific address then it will not match what the logic is checking for.

The only alternatives that work are to make the destination any or to use a standard access list.

HTH

Rick

HTH

Rick

Rick,

I am confused by this post. If you change the direction of the access-class from in to out, then you are no longer controlling who can get remote access to the router and are controlling where the router can telnet or SSH TO.

Understood which is why I mentioned your post in my previous post. According to the OPs original acl, they're allowing everything into that one address anyway:

access-list 123 permit tcp any host 218.248.17.1 eq ssh

access-list 123 permit tcp host 218.248.17.2 host 218.248.17.1 eq telnet

access-list 123 deny any any log

It was because of this line was why I said change the direction of the access-class command and it would work. Either way, I agree that you would want to tie it down by the source address as opposed to the destination.

John

HTH, John *** Please rate all useful posts ***

Hi Rick/Jhon,

Thanks for your post. But in this scenario I cannot use standard ACL because in the same router i must allow both SSH and TELNET because users from Internet will use only SSH and users in LAN will use TELNET. Hope you understand the requirement.

How generally this situation is handled. Looking for your expertise.

RBK

Here's what I would do:

For the LAN users (218.248.17.x), I would create an acl that would allow them only telnet, and then allow everyone else ssh:

Try your acl like this:

deny tcp 218.248.17.0 0.0.0.255 any eq 22

permit tcp 218.248.17.0 0.0.0.255 any eq 23

permit tcp any any eq 22

deny ip any any

This will deny any of your local users access to the routers via ssh, and they would have to use telnet. You would allow everyone else access into the router with SSH, but it would deny telnet (deny ip any any).

Apply it inbound on the line:

line vty 0 4

access-class TELNET in

transport input telnet ssh

You can tie this acl down even further by specifying just the hosts you're giving access to also. (Right now, the acl allows any host on your LAN access to the router.)

HTH,

John

HTH, John *** Please rate all useful posts ***

Hi John,

I also configured the setup the same way you mentioned. It is working very well as expected.

I raised this post mainly because of 0.0.0.0 ip address found in the logs.

However, thanks for sharing your ideas. Understood that I should standard ACL and not Extended ACL

RBK

Hi RBK,

As a side note, an advantage of using an exended access list along with rotary groups is you can control who can access a vty line on what port.

HTH,

Rakesh.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco