R.E.F.L.E.C.T

Here's the topology:

R1 --INSIDE--> R4 --OUTSIDE--> R5

We are going to apply a reflexive ACL on R4 to permit outgoing telnet, web and ping traffic.

Let's go to R4 and create our outbound ACL with the keyword "reflect" used to create our reflexive ACL.

R4(config)#ip access-list extended OUTBOUND
R4(config-ext-nacl)#permit tcp any any eq 23 reflect ?
WORD Access-list name
R4(config-ext-nacl)#permit tcp any any eq 23 reflect MIRROR
R4(config-ext-nacl)#permit tcp any any eq 80 reflect MIRROR
R4(config-ext-nacl)#permit icmp any any echo reflect MIRROR
R4(config-ext-nacl)#exit

Next we "evaluate" the reflexive ACL on our inbound ACL (note that I am doing OSPF between R4 and R5 and I don't want the adjacency to break).

R4(config)#ip access-list extended INBOUND
R4(config-ext-nacl)#evaluate MIRROR
R4(config-ext-nacl)#permit ospf any any
R4(config-ext-nacl)#deny ip any any log
R4(config-ext-nacl)#exit
R4(config)#

Apply these ACLs inbound and outbound on your outside interface, in my case S1/0:

R4(config)#int s1/0
R4(config-if)#ip access-group INBOUND in
R4(config-if)#ip access-group OUTBOUND out

Let's do some telnetting from R1 to R5

R1#telnet 155.1.5.5
Trying 155.1.5.5 ... Open

User Access Verification

Username: cisco

Flip over to R4 for Verification:

R4#show ip access-lists MIRROR
Reflexive IP access list MIRROR
permit tcp host 155.1.5.5 eq telnet host 155.1.4.4 eq 58347 (51 matches) (time left 298)
R4#

Let's examine the ACL MIRROR, The source is our telnet destination (the device we are telnetting to). This ACL is being used inbound on our outside interface to allow return traffic. Also I should note that R4 is doing NAT, with 155.1.4.4 being the translated address of R1's actual interface address (10.0.0.1). So you can see reflexive ACL's are very neat because they automatically allow for return traffic while we filter inbound and outbound.

SSH for VTY access

This is a very simple lab for SSH access:

R1 and R2 connected to same LAN
R1 will be the client, R4 the server

Let's enable SSH on R2:

R2(config)#ip domain-name theseblues.com

R2(config)#crypto key generate rsa
The name for the keys will be: R2.theseblues.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]:
% Generating 512 bit RSA keys, keys will be non-exportable...[OK]

R2(config)#
*Mar 1 00:18:50.259: %SSH-5-ENABLED: SSH 1.99 has been enabled
R2(config)#
R2(config)#line vty 0 4
R2(config-line)#login local
R2(config-line)#transport input ssh
R2(config-line)#exit
R2(config)#username dh password blues

Let's SSH from R1:

R1#ssh ?
-c Select encryption algorithm
-l Log in using this user name
-m Select HMAC algorithm
-o Specify options
-p Connect to this port
-v Specify SSH Protocol Version
WORD IP address or hostname of a remote system

R1#ssh -l dh 192.168.0.2

Password:

R2>en
% No password set
R2>

Forgot the enable password! You know what to do...

BGP no-export community

This is gonna be short and hopefully sweet. I'll leave some blanks in here so you can fill in the rest...

R4 (AS3) connects to R1 via EBGP
R1 connects to R2 via IBGP (AS 2)
R2 connects to R5 (AS1) via EBGP

We don't want AS2 to become a transit AS between R4 and R5 so we can use the no-export community to accomplish this. There are several ways to do is but here is a way with using the as-path access-lists. AS-path access-lists are awesome because they use regexp.

So on R1 we create an AS-path access list to match any routes originating in R4 AS:

ip as-path access-list 1 permit _3$

Then we create a route-map and apply it to the R2 neighbor going outbound:

route-map noexport permit 10
match as-path 1
set community no-export

route-map noexport permit 20

router bgp 2
neighbor 155.1.23.2 send-community
neighbor 155.1.23.2 route-map noexport out

Now on R2 we have this:

R2#show ip bgp 204.12.1.0 | inc Community
Community: no-export

R5 does not have the route!

R5#show ip bgp 204.12.1.0
% Network not in table
R5#

You can do the reverse on R2 to accomplish the two way restriction. Also note that R4 can bypass this by prepending an AS# to its routes! A better way would be to add the no-export community to all routes learned from R4 not just the ones originating in R4's AS. But I just wanted to see the flexibility of route-maps and as-path access lists with communities.