Showing posts with label reflexive acl. Show all posts
Showing posts with label reflexive acl. Show all posts

Saturday, October 18, 2008

Reflexive ACL and PING

Following on from the 'Reflexive ACL and Traceroute' post i now look at some anomolies i found when generating locally based traffic on the router carrying the reflexive acl.

With i try a ping from R3 to BB1 everything works as expected.

R3#P 200.1.1.1

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


When i try a ping from R6 to BB1 the same cannot be said...

R6#P 200.1.1.1

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


This can be explained because locally generated traffic does not run through that routers interfaces. If it is a requirement for locally based pings to execute successfully this leaves a small problem. In this post i offer two solutions to this problem.

This first is simply to allow icmp any any echo-reply on the inbound acl, effectively circunventing the reflexive acl logic.

The second solution ensures locally based traffic 'flows through' the same reflexive acl logic by 'fooling' the router into thinking this traffic has been originated externally.

ip access-list extended LOCAL
permit tcp any any
permit icmp any any
route-map LOCAL
match ip address LOCAL
set interface Loopback0

ip local policy route-map LOCAL


I now try the ping test again....

R6#P 200.1.1.1

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


Additionally since i matched locally generated tcp traffic i also test locally generated telnet traffic

R6#telnet 200.1.1.1
Trying 200.1.1.1 ... Open

Reflexive ACL and Traceroute




In this post i describe reflexive acls and their implementation. In addition i write about the use of traceroute when used in conjunction with a reflexive acl.

The requirement with the above topology is that R6 is secured from unauthorised access from bb1. R6 should only allow TCP, UDP and ICMP traffic in from bb1 if it has been originated from behind R6. Additionally ensure traceroute can be succesfully executed from behind R6.

I create a reflexive acl to meet this requirement. On the outside interface S2/0 i create and apply my 'reflect' acl and then on the same interface i allow this traffic back in with the evaluate statement as follows:-

ip access-list extended REFLECT
permit tcp any any reflect RICH
permit udp any any reflect RICH
permit icmp any any echo reflect RICH
permit ip any any

int s2/0
ip access-group REFLECT out

As per the lab requirement the REFLECT acl has line statements for tcp, udp and icmp traffic, along with a generic permit as there is no requirement to prevent any outbound traffic.

I then create the inbound ACL for the s2/0 interface. Care needs to be taken to ensure any existing routing protocol traffic is not disrupted.

ip access-list extended INACL
permit udp any any eq rip
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate RICH
deny ip any any log

int s2/0
ip access-group INACL in

From R3 i now try an outbound tcp session to ensure the reflexive acl is acting as it should

R3#telnet 200.1.1.1

Trying 200.1.1.1 ... Open

Success! I examine the acls on R6 and can see the relexive acl has come into effect..

R6#s ip access-list RICH

Reflexive IP access list RICH permit tcp host 200.1.1.1 eq telnet host 136.1.136.3 eq 48296 (27 matches)(time left 7)


Now i try traceroute from R3 as per the lab requirement.

Rack1R3#TRACE 200.1.1.1

Type escape sequence to abort.
Tracing the route to 200.1.1.1
1 136.1.136.6 496 msec 996 msec 392 msec
2 * * *
3 * * *
4 * * *
5 * * *

Failure! I examine the relexive acl on R6


R6#s ip access-list RICH

Reflexive IP access list RICH permit udp host 200.1.1.1 eq 33480 host 136.1.136.3 eq 37054 (1 match) (time left 19)

I can see the reflexive acl has been brought into action, but the traceroute is still failing!!

I run a packet capture to further determine problem. From this i can see that the outbound traceroute packet leaves as a UDP packet, however the response coming from the far end router arrives as an ICMP port unreachable packet!

This explains the failure as this traffic exchange falls foul on the refelexive acl logic i.e. the returning packet stream does not match the outbound.
To get around this problem requires an explicit entry in the inbound ACL to permit icmp port unreachable messages.

R6(config)#ip access-list ext INACL
R6(config-ext-nacl)#41 permit icmp any any port port-unreachable

I then try traceroute from R3 this time with success!

R3#TRACE 200.1.1.1
Type escape sequence to abort.

Tracing the route to 200.1.1.1
1 136.1.136.6 724 msec 548 msec 208 msec
2 54.1.3.254 1272 msec 876 msec 1056 msec

Another example of a protocol that falls foul of reflexive acl logic is active FTP. With this protocol the control and data sessions are initiated on different ports in different directions, something that will break the reflexive acl model.