Mailing List Archive: Cisco: NSP

ip access list rfc1918 help please

Index | Next | Previous | View Threaded

mike-cisconsplist at tiedyenetworks

Jun 23, 2012, 2:42 PM

Post #1 of 8 (777 views)
Permalink

ip access list rfc1918 help please

Howdy,

I am trying to filter out rfc1918 addresses as either source or
destination addresses for my pppoe connected subscribers. Each
subscriber has a radius item 'Filter-Id' with the name of a filter, with
the majority being 'customer_filter1', and it seems that although this
is in fact being applied to the virtual-access interfaces per customer,
it doesn't work as I expect since I can clearly see traffic from
customer -> rfc1918 address space still being forwarded.

Here's a sample 'sh ip interface" showing the filter being applied:

c7201-bras#sh ip interface virtual-access 190
Virtual-Access190 is up, line protocol is up
Interface is unnumbered. Using address of Loopback0 (x.x.x.x)
Broadcast address is 255.255.255.255
Peer address is y.y.y.y
MTU is 1492 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is customer_filter1
Inbound access list is not set

etc, etc

Here is the filter itself:

ip access-list extended customer_filter1
deny ip host 0.0.0.0 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 224.0.0.0 31.255.255.255 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip any host 0.0.0.0
deny ip any 127.0.0.0 0.255.255.255
deny ip any 192.0.2.0 0.0.0.255
deny ip any 224.0.0.0 31.255.255.255
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any

Any ideas?

Mike-
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

randy_94108 at yahoo

Jun 23, 2012, 3:37 PM

Post #2 of 8 (748 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

--- On Sat, 6/23/12, Mike <mike-cisconsplist [at] tiedyenetworks> wrote:

> From: Mike <mike-cisconsplist [at] tiedyenetworks>
> Subject: [c-nsp] ip access list rfc1918 help please
> To: "'Cisco-nsp'" <cisco-nsp [at] puck>
> Date: Saturday, June 23, 2012, 2:42 PM
>
> Howdy,
>
>     I am trying to filter out rfc1918
> addresses as either source or destination addresses for my
> pppoe connected subscribers. Each subscriber has a radius
> item 'Filter-Id' with the name of a filter, with the
> majority being 'customer_filter1', and it seems that
> although this is in fact being applied to the virtual-access
> interfaces per customer, it doesn't work as I expect since I
> can clearly see traffic from customer -> rfc1918 address
> space still being forwarded.
>
> Here's a sample 'sh ip interface" showing the filter being
> applied:
>
>
> c7201-bras#sh ip interface virtual-access 190
> Virtual-Access190 is up, line protocol is up
> Interface is unnumbered. Using address of Loopback0
> (x.x.x.x)
> Broadcast address is 255.255.255.255
> Peer address is y.y.y.y
> MTU is 1492 bytes
> Helper address is not set
> Directed broadcast forwarding is disabled
> Outgoing access list is customer_filter1
> Inbound access list is not set
>
> etc, etc
>
> Here is the filter itself:
>
> ip access-list extended customer_filter1
> deny   ip host 0.0.0.0 any
> deny   ip 127.0.0.0 0.255.255.255 any
> deny   ip 192.0.2.0 0.0.0.255 any
> deny   ip 224.0.0.0 31.255.255.255 any
> deny   ip 10.0.0.0 0.255.255.255 any
> deny   ip 172.16.0.0 0.15.255.255 any
> deny   ip 192.168.0.0 0.0.255.255 any
> deny   ip any host 0.0.0.0
> deny   ip any 127.0.0.0 0.255.255.255
> deny   ip any 192.0.2.0 0.0.0.255
> deny   ip any 224.0.0.0 31.255.255.255
> deny   ip any 10.0.0.0 0.255.255.255
> deny   ip any 172.16.0.0 0.15.255.255
> deny   ip any 192.168.0.0 0.0.255.255
> permit ip any any
>
> Any ideas?
>
> Mike-

customer-TO-rfc1918 is INBOUND on virtual-access 190
You have an outbound acl applied. In that regard, I would say it is "working as expected".
./Randy

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

kgraham at industrial-marshmallow

Jun 24, 2012, 10:30 AM

Post #3 of 8 (742 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

Do you need to do this via ACLs? For the inbound case, strict unicast RPF would handle this (and more) implicitly. For the outbound, do you have any 1918 routes? If not, just add statics to Null0.

[sent from my mobile]

On Jun 23, 2012, at 3:37 PM, Randy <randy_94108 [at] yahoo> wrote:

> --- On Sat, 6/23/12, Mike <mike-cisconsplist [at] tiedyenetworks> wrote:
>
>> From: Mike <mike-cisconsplist [at] tiedyenetworks>
>> Subject: [c-nsp] ip access list rfc1918 help please
>> To: "'Cisco-nsp'" <cisco-nsp [at] puck>
>> Date: Saturday, June 23, 2012, 2:42 PM
>>
>> Howdy,
>>
>> I am trying to filter out rfc1918
>> addresses as either source or destination addresses for my
>> pppoe connected subscribers. Each subscriber has a radius
>> item 'Filter-Id' with the name of a filter, with the
>> majority being 'customer_filter1', and it seems that
>> although this is in fact being applied to the virtual-access
>> interfaces per customer, it doesn't work as I expect since I
>> can clearly see traffic from customer -> rfc1918 address
>> space still being forwarded.
>>
>> Here's a sample 'sh ip interface" showing the filter being
>> applied:
>>
>>
>> c7201-bras#sh ip interface virtual-access 190
>> Virtual-Access190 is up, line protocol is up
>> Interface is unnumbered. Using address of Loopback0
>> (x.x.x.x)
>> Broadcast address is 255.255.255.255
>> Peer address is y.y.y.y
>> MTU is 1492 bytes
>> Helper address is not set
>> Directed broadcast forwarding is disabled
>> Outgoing access list is customer_filter1
>> Inbound access list is not set
>>
>> etc, etc
>>
>> Here is the filter itself:
>>
>> ip access-list extended customer_filter1
>> deny ip host 0.0.0.0 any
>> deny ip 127.0.0.0 0.255.255.255 any
>> deny ip 192.0.2.0 0.0.0.255 any
>> deny ip 224.0.0.0 31.255.255.255 any
>> deny ip 10.0.0.0 0.255.255.255 any
>> deny ip 172.16.0.0 0.15.255.255 any
>> deny ip 192.168.0.0 0.0.255.255 any
>> deny ip any host 0.0.0.0
>> deny ip any 127.0.0.0 0.255.255.255
>> deny ip any 192.0.2.0 0.0.0.255
>> deny ip any 224.0.0.0 31.255.255.255
>> deny ip any 10.0.0.0 0.255.255.255
>> deny ip any 172.16.0.0 0.15.255.255
>> deny ip any 192.168.0.0 0.0.255.255
>> permit ip any any
>>
>> Any ideas?
>>
>> Mike-
>
>
> customer-TO-rfc1918 is INBOUND on virtual-access 190
> You have an outbound acl applied. In that regard, I would say it is "working as expected".
> ./Randy
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

gert at greenie

Jun 24, 2012, 12:02 PM

Post #4 of 8 (744 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

Hi,

On Sat, Jun 23, 2012 at 02:42:04PM -0700, Mike wrote:
> I am trying to filter out rfc1918 addresses as either source or
> destination addresses for my pppoe connected subscribers. Each

Why not

a) turn on uRPF filtering on the virtual-template
("ip verify unicast reverse")
-> this takes care of *any* garbage source address the customer
might send you, not just RFC1918 space (see also BCP38).

b) null-route the RFC1918 space
-> this takes care of the destination addresses

that way you can get much more benefits with less effort.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net

cisco-nsp at itpro

Jun 24, 2012, 11:49 PM

Post #5 of 8 (727 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

Hi

It is probably also worth looking at RFC5735 for other IP addresses that
could be filtered.

Ivan

On 24/Jun/2012 10:37 a.m., Randy wrote:
> --- On Sat, 6/23/12, Mike <mike-cisconsplist [at] tiedyenetworks> wrote:
>
>> From: Mike <mike-cisconsplist [at] tiedyenetworks>
>> Subject: [c-nsp] ip access list rfc1918 help please
>> To: "'Cisco-nsp'" <cisco-nsp [at] puck>
>> Date: Saturday, June 23, 2012, 2:42 PM
>>
>> Howdy,
>>
>> I am trying to filter out rfc1918
>> addresses as either source or destination addresses for my
>> pppoe connected subscribers. Each subscriber has a radius
>> item 'Filter-Id' with the name of a filter, with the
>> majority being 'customer_filter1', and it seems that
>> although this is in fact being applied to the virtual-access
>> interfaces per customer, it doesn't work as I expect since I
>> can clearly see traffic from customer -> rfc1918 address
>> space still being forwarded.
>>
>> Here's a sample 'sh ip interface" showing the filter being
>> applied:
>>
>>
>> c7201-bras#sh ip interface virtual-access 190
>> Virtual-Access190 is up, line protocol is up
>> Interface is unnumbered. Using address of Loopback0
>> (x.x.x.x)
>> Broadcast address is 255.255.255.255
>> Peer address is y.y.y.y
>> MTU is 1492 bytes
>> Helper address is not set
>> Directed broadcast forwarding is disabled
>> Outgoing access list is customer_filter1
>> Inbound access list is not set
>>
>> etc, etc
>>
>> Here is the filter itself:
>>
>> ip access-list extended customer_filter1
>> deny ip host 0.0.0.0 any
>> deny ip 127.0.0.0 0.255.255.255 any
>> deny ip 192.0.2.0 0.0.0.255 any
>> deny ip 224.0.0.0 31.255.255.255 any
>> deny ip 10.0.0.0 0.255.255.255 any
>> deny ip 172.16.0.0 0.15.255.255 any
>> deny ip 192.168.0.0 0.0.255.255 any
>> deny ip any host 0.0.0.0
>> deny ip any 127.0.0.0 0.255.255.255
>> deny ip any 192.0.2.0 0.0.0.255
>> deny ip any 224.0.0.0 31.255.255.255
>> deny ip any 10.0.0.0 0.255.255.255
>> deny ip any 172.16.0.0 0.15.255.255
>> deny ip any 192.168.0.0 0.0.255.255
>> permit ip any any
>>
>> Any ideas?
>>
>> Mike-
>
>
> customer-TO-rfc1918 is INBOUND on virtual-access 190
> You have an outbound acl applied. In that regard, I would say it is "working as expected".
> ./Randy
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

mike-cisconsplist at tiedyenetworks

Jun 26, 2012, 5:17 PM

Post #6 of 8 (705 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

On 06/24/2012 12:02 PM, Gert Doering wrote:
> Hi,
>
> On Sat, Jun 23, 2012 at 02:42:04PM -0700, Mike wrote:
>
>> I am trying to filter out rfc1918 addresses as either source or
>> destination addresses for my pppoe connected subscribers. Each
>>
> Why not
>
> a) turn on uRPF filtering on the virtual-template
> ("ip verify unicast reverse")
> -> this takes care of *any* garbage source address the customer
> might send you, not just RFC1918 space (see also BCP38).
>
> b) null-route the RFC1918 space
> -> this takes care of the destination addresses
>
> that way you can get much more benefits with less effort.
>
> gert
>

Actually I do have urpf for exactly the reason you stated, but thanks. I
had the filter turned around backwards so it was not being very
effective. I added

radius-server attribute 11 default direction in

and suddently the filter started to work as I thought it should, namely,
stop packets from customers to rfc1918 space. Based on your and other
inputs however, I'm beginning to rethink my strategy. I want to be able
to bypass filtering in some cases, and I'd also like to have filtering
based on a dynamic set... it's possible to null route bad destinations,
but can a routing table be used to say 'drop all packets from these
prefixes'?

Thanks.
Mike-
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

randy_94108 at yahoo

Jun 26, 2012, 6:31 PM

Post #7 of 8 (699 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

--- On Tue, 6/26/12, Mike <mike-cisconsplist [at] tiedyenetworks> wrote:

> From: Mike <mike-cisconsplist [at] tiedyenetworks>
> Subject: Re: [c-nsp] ip access list rfc1918 help please
> To:
> Cc: "'Cisco-nsp'" <cisco-nsp [at] puck>
> Date: Tuesday, June 26, 2012, 5:17 PM
> On 06/24/2012 12:02 PM, Gert Doering
> wrote:
> > Hi,
> >
> > On Sat, Jun 23, 2012 at 02:42:04PM -0700, Mike wrote:
> >
> >>     I am trying to filter out
> rfc1918 addresses as either source or
> >> destination addresses for my pppoe connected
> subscribers. Each
> >>
> > Why not
> >
> > a) turn on uRPF filtering on the
> virtual-template
> >    ("ip verify unicast
> reverse")
> >    -> this takes
> care of *any* garbage source address the customer
> >    might send you, not just
> RFC1918 space (see also BCP38).
> >
> > b) null-route the RFC1918 space
> >    -> this takes
> care of the destination addresses
> >
> > that way you can get much more benefits with less
> effort.
> >
> > gert
> >
>
> Actually I do have urpf for exactly the reason you stated,
> but thanks. I had the filter turned around backwards so it
> was not being very effective. I added
>
> radius-server attribute 11 default direction in
>
> and suddently the filter started to work as I thought it
> should, namely, stop packets from customers to rfc1918
> space. Based on your and other inputs however, I'm beginning
> to rethink my strategy. I want to be able to bypass
> filtering in some cases, and I'd also like to have filtering
> based on a dynamic set... it's possible to null route bad
> destinations, but can a routing table be used to say 'drop
> all packets from these prefixes'?
>
> Thanks.
> Mike-

Yes -

"ip policy route-map foo"

route-map foo permit 10 will match an extended acl for desired source& dest prefixes.
and set next-hop to 192.0.2.1(eg)

and a static route:

ip route 192.0.2.1 255.255.255.255 Null0

will do the trick.
./Randy

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

gert at greenie

Jun 27, 2012, 12:31 AM

Post #8 of 8 (681 views)
Permalink

Re: ip access list rfc1918 help please [In reply to]

Hi,

On Tue, Jun 26, 2012 at 05:17:22PM -0700, Mike wrote:
> Actually I do have urpf for exactly the reason you stated, but thanks. I
[..]
> based on a dynamic set... it's possible to null route bad destinations,
> but can a routing table be used to say 'drop all packets from these
> prefixes'?

In combination with uRPF, yes. If the route points elsewhere, and uRPF
is active on the interface where the packets are coming in, uRPF will
drop the packet.

Now, on your upstream interfaces, blindly enabling uRPF is going to
hurt, as asymmetry there is likely and uRPF will then drop legitimate
packets - so you need to use "ip verify unicast source reachable-via any",
and "filter these prefixes!" prefixes must be routed to "null0" for
this to be effective.

gert

--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads