From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Wed Nov 26 2003 - 20:41:28 GMT-3
Ken,
As you saw the router will complain about the naming:
Rack11R2(config)#ip access-list extended REFLEXIVE
Rack11R2(config-ext-nacl)#evaluate REFLEXIVE
Access-list type conflicts with prior definition
As a side note, you can not have a named ACL called 'in' or 'out' ;-)
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Ken.Farrington@barclayscapital.com
Sent: Wednesday, November 26, 2003 2:04 PM
To: bmcgahan@internetworkexpert.com; Nigel.Johnson@barclayscapital.com;
ccielab@groupstudy.com
Subject: RE: Reflective ACLs
Absolutley perfect reply mate :)
One question is on the first issue.
And its just a thought..... probably a dumb one at that, but
you now have an access-list called REFLEXIVE when you do a show ip
access-list which is your "state table"
your config is
R1:
interface Ethernet0/0
ip address 12.0.0.1 255.0.0.0
ip access-group INBOUND in
ip access-group OUTBOUND out
what would happen if rather that using "ip access-group INBOUND in" you
used the command "ip access-group REFLEXIVE in" ?
so rather than using an access-list that uses a reference (ie evaluate) to
the state table, you use the state table directly.
R1:
interface Ethernet0/0
ip address 12.0.0.1 255.0.0.0
ip access-group REFLEXIVE in
ip access-group OUTBOUND out
It just a thought ? after all, when you do a show ip access-list, the
INBOUND is shown as an "ip extended acl" and the REFLEXIVE is a "reflexive
acl"
I tried it and it did not work, so i gues thats that.
Thx dude
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: 26 November 2003 20:53
To: Johnson, Nigel: IT (LDN); ccielab@groupstudy.com; Farrington, Ken:
IT (LDN)
Subject: RE: Reflective ACLs
Ken,
Reflexive access-lists and content based access-control (CBAC) can
be thought of as subsets what the PIX firewall does. In order for a
firewall to be "stateful" it has to know what traffic has been originated
from inside the network. A "stateful" firewall means that when traffic
leaves the network it is noted in a state table. When traffic tries to come
back into the network it is only allowed if there is a previously created
entry in the state table. A reflexive list uses the same principle.
When traffic is leaving the network it is "reflected" to the state
table. When traffic tries to come back in it is "evaluated" to see if there
is a previous entry in the state table. If there is no entry (and no
explicit permit statement) the traffic is denied. Without the "reflect"
statement, nothing would show up in the state table and everything would be
effectively denied.
For the second issue you are correct. An outbound access-list does
not affect locally generated traffic by the router. This means that traffic
the router originates (routing protocol traffic, telnet, ping, etc) will not
get evaluated. There are two choices to deal with this problem, you can
either explicitly permit this traffic to return, or you can policy route all
locally generated traffic to another local interface first. The first
method is easier, and the second is potentially more secure. Take the
following example:
R1---R2
R1 and R2 are directly connected over an Ethernet segment with the IP
network 12.0.0.0/8. R1 is applying a reflexive access-list outbound towards
R2. Its config is as follows:
R1:
interface Ethernet0/0
ip address 12.0.0.1 255.0.0.0
ip access-group INBOUND in
ip access-group OUTBOUND out
!
ip access-list extended INBOUND
evaluate REFLEXIVE
deny ip any any
ip access-list extended OUTBOUND
permit tcp any any reflect REFLEXIVE
permit udp any any reflect REFLEXIVE
permit icmp any any reflect REFLEXIVE
R1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#show access-list INBOUND
Extended IP access list INBOUND
10 evaluate REFLEXIVE
20 deny ip any any (10 matches) <-- Traffic is denied as it tries to
re-enter the Ethernet interface connecting to R2.
1st solution: manually allow traffic back in
R1(config)#ip access-list ex INBOUND
R1(config-ext-nacl)#1 permit icmp host 12.0.0.2 host 12.0.0.1 echo-reply
R1#show access-list INBOUND
Extended IP access list INBOUND
1 permit icmp host 12.0.0.2 host 12.0.0.1 echo-reply
10 evaluate REFLEXIVE
20 deny ip any any (10 matches)
R1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Now ICMP echo-replies are allowed to come back in from R2.
2nd method: policy route locally generated traffic
R1#telnet 12.0.0.2
Trying 12.0.0.2 ...
% Connection timed out; remote host not responding <--telnet traffic denied
from returning from R2.
R1(config)#int loopback 0
R1(config-if)#ip ad 1.1.1.1 255.255.255.255
R1(config-if)#exit
R1(config)#route-map LOCAL_POLICY
R1(config-route-map)#set interface loopback 0
R1(config-route-map)#exit
R1(config)#ip local policy route-map LOCAL_POLICY
R1(config)#END
R1#telnet 12.0.0.2
Trying 12.0.0.2 ... Open
Password required, but none set
[Connection to 12.0.0.2 closed by foreign host]
R1#show access-list REFLEXIVE
Reflexive IP access list REFLEXIVE
permit tcp host 12.0.0.2 eq telnet host 12.0.0.1 eq 11468 (22 matches)
(time left 3)
Now all locally generated traffic is treated as transit traffic. Be
careful of using this method in production as it can have a negative impact
on CPU utilization.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 708-362-1418 (Outside the US and Canada)
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Nigel.Johnson@barclayscapital.com
> Sent: Wednesday, November 26, 2003 9:25 AM
> To: ccielab@groupstudy.com
> Subject: RE: Reflective ACLs
>
> I'd guess that it's because there isn't an implicit deny at the end of a
> reflexive ACL ('inbound' in your example) so you need to nest it to
> prevent
> allowing all traffic.
>
> You would need to specifically allow BGP, EIGRP, so your 'inbound-eval'
> access-list would become:
>
> Extended IP access list inbound-eval
> permit bgp any any
> permit eigrp any any
> evaluate inbound
>
>
> Cheers,
> Nige
>
>
> -----Original Message-----
> From: Farrington, Ken: IT (LDN)
> Sent: 26 November 2003 12:24
> To: ccielab@groupstudy.com
> Subject: Reflective ACLs
>
>
> Hello,
>
> Couple of questions re Reflecive ACLs.
>
> Firstly, Why do I need the evaluate ACL. Cant I just use the "inbound"
> ACL
> on the access-group on the
> interface, (The actual reflexive access-list) rather than the
> "inbound-eval" the acl with the evaluate command in? Say this is the only
> entry in the ACL.
>
> Secondly, What about packets generated from the actual router, ie, eigrp,
> ospf, BGP, ICMP etc etc. These
> packets as they are not transient to the router dont seem to get thru. Is
> it becuase they are originated from the router processor itself? I would
> imagine that multicast traffic for eigrp, ospf, ripv2 would have a problem
> with the reflective ACL and there source would be say 30.96.100.18 and
> dest
> would be the mcast address. This reflected i would assume show in the
> ACL,
> a source of the mcast address and the dest of the 30.96.100.18.
>
> Please could someone explain this to me?
>
> Many thx indeed,
> Ken
>
>
>
> MMmR01#
> MMmR01#
> !
> interface Vlan50
> ip address 30.96.100.18 255.255.255.252
> ip access-group inbound-eval in
> ip access-group outbound out
> ip pim sparse-dense-mode
> !
> MMmR01#
> MMmR01#
> Reflexive IP access list inbound
> permit tcp host 30.96.100.17 eq telnet host 30.96.100.62 eq 63489 (32
> matches) (time left 1)
> permit icmp host 30.96.100.1 host 30.96.100.42 (12 matches) (time
> left
> 206)
> permit udp host 224.0.1.40 eq pim-auto-rp host 30.96.100.25 eq
> pim-auto-rp (3 matches) (time left 277)
> permit udp host 30.96.100.1 eq snmp host 30.96.100.42 eq 60114 (11
> matches) (time left 189)
> permit udp host 30.96.100.2 eq snmp host 30.96.100.42 eq 60114 (62
> matches) (time left 288)
> permit icmp host 30.96.100.17 host 30.96.100.62 (26 matches) (time
> left
> 227)
> permit icmp host 30.96.100.17 host 30.96.100.42 (12 matches) (time
> left
> 138)
> permit udp host 224.0.1.39 eq pim-auto-rp host 30.96.100.25 eq
> pim-auto-rp (7 matches) (time left 268)
> permit udp host 30.96.100.17 eq snmp host 30.96.100.42 eq 60114 (114
> matches) (time left 288)
> !
> Extended IP access list inbound-eval
> evaluate inbound
> !
> Extended IP access list outbound
> permit ip any any reflect inbound
> MMmR01#
>
>
>
>
> ________________________________________________________________
> Ken Farrington
> Global Networks, Barclays Capital, 5 The North Colonnade, Canary
> Wharf, London, E14 4BB
> * Tel : 020 7773 3550
> * Mob : 07768-866655
> * ken.farrington@barcap.com
>
>
>
>
> ------------------------------------------------------------------------
> For more information about Barclays Capital, please
> visit our web site at http://www.barcap.com.
>
>
> Internet communications are not secure and therefore the Barclays
> Group does not accept legal responsibility for the contents of this
> message. Although the Barclays Group operates anti-virus programmes,
> it does not accept responsibility for any damage whatsoever that is
> caused by viruses being passed. Any views or opinions presented are
> solely those of the author and do not necessarily represent those of the
> Barclays Group. Replies to this email may be monitored by the Barclays
> Group for operational or business reasons.
>
> ------------------------------------------------------------------------
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 12:29:18 GMT-3