[cisco-bba] ACLs on Virtual-Access templates

Sat Jan 31 23:16:40 EST 2009

Yes, I think it's all on.  Here's some output on my own connection.  I
didn't have to drop my PPPoE link for it to show up.  

Perhaps the ACL has precedence over the uRPF, and that's why I'm seeing it
logged and blocked there instead of via uRPF?

Router#sh user | inc fbulk

  Vi3.72       fbulk              PPPoE        -        b.c.d.e

Router#sh run int vi3.72

Building configuration...

Current configuration : 153 bytes

!

interface Virtual-Access3.72

 ip access-group 125 in

 ip verify unicast source reachable-via rx

 ip tcp adjust-mss 1452

 no snmp trap link-status

end

Router#sh int Vi3.72 configuration

Virtual-Access3.72 is a PPP over Ethernet link (sub)interface

Derived configuration : 292 bytes

!

interface Virtual-Access3.72

 ip unnumbered Loopback11

 ip access-group 125 in

 ip verify unicast source reachable-via rx

 ip tcp adjust-mss 1452

 peer default ip address dhcp

 no snmp trap link-status

 ppp mtu adaptive

 ppp authentication pap

 ppp ipcp dns a.b.c.d e.f.g.h

end

Router#sh ip interface Vi3.72

Virtual-Access3.72 is up, line protocol is up

  Interface is unnumbered. Using address of Loopback11 (b.c.d.1)

  Broadcast address is 255.255.255.255

  Peer address is b.c.d.e

  MTU is 1492 bytes

  Helper address is not set

  Directed broadcast forwarding is disabled

  Outgoing access list is not set

  Inbound  access list is 125

  Proxy ARP is enabled

  Local Proxy ARP is disabled

  Security level is default

  Split horizon is enabled

  ICMP redirects are always sent

  ICMP unreachables are always sent

  ICMP mask replies are never sent

  IP fast switching is enabled

  IP Flow switching is disabled

  IP CEF switching is enabled

  IP CEF switching turbo vector

  IP CEF turbo switching turbo vector

  IP multicast fast switching is enabled

  IP multicast distributed fast switching is disabled

  IP route-cache flags are Fast, CEF

  Router Discovery is disabled

  IP output packet accounting is disabled

  IP access violation accounting is disabled

  TCP/IP header compression is disabled

  RTP/IP header compression is disabled

  Probe proxy name replies are disabled

  Policy routing is disabled

  Network address translation is disabled

  WCCP Redirect outbound is disabled

  WCCP Redirect inbound is disabled

  WCCP Redirect exclude is disabled

  BGP Policy Mapping is disabled

  Input features: Access List, uRPF, TCP Adjust MSS

  Output features: TCP Adjust MSS

  IP verify source reachable-via RX

   0 verification drops

   0 suppressed verification drops

   0 verification drop-rate

Router#

From: Arie Vayner [mailto:arievayner at gmail.com] 
Sent: Saturday, January 31, 2009 3:49 PM
To: Frank Bulk
Cc: cisco-bba at puck.nether.net
Subject: Re: [cisco-bba] ACLs on Virtual-Access templates

Frank,

uRFP should be the right way to block packets from the client as a source...
After you connect, do you see the uRPF feature enabled on the Virtual-Access
(show run interface and show ip interface)?

Arie

On Sat, Jan 31, 2009 at 11:35 PM, Frank Bulk <frnkblk at iname.com> wrote:

Is there a way to build an ACL on a Virtual-Access template such that the
connection can only use the IP address given to it by IPCP?

I applied strict uRPF to the Virtual-Access template, but that didn't stop
this kind of traffic:

Jan 31 15:23:21 a.b.c.d 38279: Jan 31 15:23:20.964 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 80.212.149.228(55190) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:32 a.b.c.d 38287: Jan 31 15:23:31.476 CST: %SEC-6-IPACCESSLOGP:
list 125 denied tcp 222.172.244.3(2047) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:33 a.b.c.d 38288: Jan 31 15:23:32.784 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 151.48.173.200(25235) -> 192.168.0.0(19427), 1 packet
Jan 31 15:23:36 a.b.c.d 38290: Jan 31 15:23:34.884 CST: %SEC-6-IPACCESSLOGP:
list 125 denied udp 58.108.93.71(13502) -> 192.168.0.0(19427), 1 packet

Those source IPs aren't mine, and are targeting an RFC1918 address.  I'm
blocking traffic originating from my PPPoA/E customers that use a source IP
address outside my netblock or are targeting an RFC198 address using an
inbound ACL on the Virtual-Access template, but it doesn't stop a a customer
from spoofing their neighbor's IP address.

I've had a basic ACL in place on our internet-facing Ethernet port (Cisco
7206VXR with NPE-400) for a long time, but I didn't having anything in place
to block RFC 1918 addresses.  I could have applied the rules to the ACL on
the Ethernet interface, but I've been told to apply an ACL as close as
possible to the source of the traffic.

To further complicate matters, I also use this router to route RFC 1918
space for corporate needs.  I keep that "separate" by using source-based
routing, but that didn't prevent PPPoA/E customers from sending a packet to
the RFC 1918 space, even if the return packet never got back to them.
Perhaps I should use a VRF for handling corporate, traffic, except that I've
never done that before and I would need to spend some time learning.

Frank

_______________________________________________
cisco-bba mailing list
cisco-bba at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-bba/attachments/20090131/eb47e409/attachment-0001.html>