From: Jay Hennigan (jay@west.net)
Date: Tue Jun 17 2003 - 01:58:01 GMT-3
On Mon, 16 Jun 2003, Jason Cash wrote:
> My question is, is the following incorrect and does it accomplish the same
> thing as the solution:
>
>
>
> interface Ethernet0
>
> description to R1 E0 (crossover)
>
> ip address 172.29.12.2 255.255.255.192
>
> ip policy route-map local23
>
> !
>
> route-map local23 permit 10
>
> match ip address 100
>
> set ip next-hop 172.29.100.5
>
> !
>
> access-list 100 permit tcp host 192.168.1.1 eq telnet 172.29.80.0 0.0.0.31
>
>
>
>
>
> The solution provided was:
>
>
>
> access-list 100 permit tcp host 192.168.1.1 172.29.80.0 0.0.0.31 eq telnet
>
>
>
> I guess I want to know the difference between the two. Would My solution
> provide the same result. I interpret mine to mean:
>
> allow traffic from host 192.168.1.1 (tcp src. port 23) to goto subnet
> 172.29.80.0/27
This is a correct interpretation, but it doesn't meet what was asked.
> I interpret the solution as:
>
> allow traffic from host 192.168.1.1 to goto subnet 172.29.80.0/27 (tcp dest.
> port 23)
>
>
> What ais the difference? Does telnet not originate from port 23 on
> occasion?
Actually, it doesn't. It originates from a random high ( > 1023) port.
And the lab proctor doesn't want a solution that works on occasion. :-)
> Is this where the problem would come into play. I get confused
> on src/dest. ports so any links to clear the confusion would be appreciated.
Think of the upper layer protocols as listening sockets. A host or
router accepting telnet has a socket listening on TCP port 23. A web
server has a socket listening on TCP port 80. A name server is listening
on UDP 53.
The host initiating the connection sends from a random high port to the
listening IP/port combination on the destination host. The reply traffic
will be from the protocol-specific port to the same random high port that
initiated the connection. So If I want to control traffic relating to
initiating a specific protocol, I target the listening port which will
be the destination. FTP-data is a special case exception.
If you were simply blocking the establishment of telnet and not applying
the list to a route-map, you could theoretically do something like the
following:
access-list 101 deny host 192.168.1.2 eq telnet any
access-list 101 permit ip any any
interface serial0
access-group 101 in
If the only route to 192.168.1.2 is serial0, this would prevent you
from establishing a telnet session with that host, but in a backwards
and unfriendly manner. What would happen is that you would send a SYN
to 192.168.1.2, but its ACK back to you originating on its telnet port
would be denied. This is the wrong way to do it as you wind up leaving a
half-open connection to the host. This is considered impolite, like
ringing the doorbell and running away. It could work in a lab scenario
to block telnet based on source port. Not recommended in the real world.
The proper way is to manipulate the destination port pertaining to the
protocol you want to control as the source is going to be a random high
port for most common protocols.
-- Jay Hennigan - CCIE #7880 - Network Administration - jay@west.net WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:59 GMT-3