Reflexive ACLs and Local Policy Routing

Two topics today: Reflexive ACLs (RACLs) and Local Policy Routing, and how they interoperate.

RACLs provide a firewall-like function.

The idea is to manually create two ACLs: inside-to-outside, and outside-to-inside.  inside-to-outside matches will be reversed into a reflexive ACL, and then evaluated as part of outside-to-inside, which would generally otherwise deny most traffic.

Here's our diagram:



R1 & R2 will represent our inside network, and R3 the outside.  R2's Fa0/1 will be our security border.  The segment IPs are represented on the diagram.  Each router is using it's router number to form its IP address (on 192.168.12.0; R2 would be 192.168.12.2, etc).  Each router also has a loopback of X.X.X.X/24, where X is the router number.

EIGRP is running on all interfaces, presently R3 can reach R1:

R3#ping 192.168.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/76 ms

Our goal is to have R1 and R2 be able to initiate connections towards R3, and R3 to be able to reply, but not initiate connections to "INSIDE".

First, we create an ACL to match our traffic exiting the INSIDE network:

ip access-list extended inside-to-outside
 permit tcp any any reflect RETURN-TRAFFIC
 permit udp any any reflect RETURN-TRAFFIC
 permit icmp any any reflect RETURN-TRAFFIC
 permit eigrp any any

The "reflect" statements will permit the traffic indicated, and also permit the reverse flow backwards.  So if R1 initiated TCP 43002 towards R3 TCP 19, the RETURN-TRAFFIC RACL will be dynamically created permitting R3's TCP 19 towards R1's TCP 43002.   We permit EIGRP at the bottom, as EIGRP isn't matched by any of the other statements, and would otherwise be denied.

We then create an ACL to deal with traffic coming in from the outside:

ip access-list extended outside-to-inside
 permit eigrp any any
 evaluate RETURN-TRAFFIC
 deny   ip any any

First, allow all EIGRP traffic - as it wasn't pushed into the RACL by the inside-to-outside ACL, we need to statically permit it back in.  Then we "evaluate" the RETURN-TRAFFIC RACL, which basically means "permit everything matched in RETURN-TRAFFIC".

R1#ping 192.168.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/47/100 ms

R1 can ping R3, and R3 can clearly reply.  Let's try some TCP:

R1#telnet 192.168.23.3
Trying 192.168.23.3 ... Open

Password required, but none set

I didn't set a password on R3, but this proves concept.

Let's take a look at the RACL:

R2#sh ip access-list RETURN-TRAFFIC
Reflexive IP access list RETURN-TRAFFIC
     permit icmp host 192.168.23.3 host 192.168.12.1  (20 matches) (time left 231)

Why only the ICMP match?  What happened to the telnet/TCP flow? 

In our case, R3 sent a FIN to R1 right after telling it a Password was required, so like any good pseudo-firewall, R2 saw the FIN and closed the flow.

Let's try this again with allowing the TCP connection to actually stay up.

R3(config)#line vty 0 903
R3(config-line)#password cisco

R1#telnet 192.168.23.3
Trying 192.168.23.3 ... Open

User Access Verification
Password:
R3>

R2#sh ip access-list RETURN-TRAFFIC
Reflexive IP access list RETURN-TRAFFIC
     permit tcp host 192.168.23.3 eq telnet host 192.168.12.1 eq 26744 (24 matches) (time left 298)
     permit icmp host 192.168.23.3 host 192.168.12.1  (10 matches) (time left 295)

Now we see the TCP match.

So let's try this from R2.

R2#ping 192.168.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Uh-oh!  R1 can reach R3 but R2 can't?  As you might remember from your CCNA days, local traffic isn't evaluated by the local router's ACLs.  So while the traffic is arriving at R3, it's never entered in the RACL, and therefore R3 replied but R2's Fa0/1 ingress ACL blocks the traffic.

We can fix this with local policy routing.

First we make an access-list that matches traffic towards R3:

ip access-list extended match_traffic_to_r3
 deny   eigrp any any  ! no need to attempting reflecting this, as it's statically permitted inbound
 permit ip any 192.168.23.0 0.0.0.255

Then we create a route-map on R2 that matches the access-list:

route-map towards_r3 permit 10
 match ip address match_traffic_to_r3
 set ip next-hop 2.2.2.2  !  2.2.2.2 is R2's loopback 0. 

Then we apply it in global config:

ip local policy route-map towards_r3

This makes R2 route packets toward R3, and therefore it gets evaluated by the inside-to-outside ACL

R2#ping 192.168.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/45/60 ms

and the flow appears in the RACL:

R2#sh ip access-list
Reflexive IP access list RETURN-TRAFFIC
     permit icmp host 192.168.23.3 host 192.168.23.2  (10 matches) (time left 297)

We can also do some funky stuff with this, because Lo0 is a /24:

R2#sh run int lo0
Building configuration...
Current configuration : 61 bytes
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
end

Lo0 will receive traffic for 2.2.2.0/24, so we could actually use the local policy routing to forward towards anything in that /24:

route-map towards_r3 permit 10
 match ip address match_traffic_to_r3
 set ip next-hop 2.2.2.78

R2#ping 192.168.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/44/64 ms

R2#sh ip access-list RETURN-TRAFFIC
Reflexive IP access list RETURN-TRAFFIC
     permit icmp host 192.168.23.3 host 192.168.23.2  (30 matches) (time left 294)

Hope you enjoyed!

Jeff