<div dir="ltr">Frank,<br><br>uRFP should be the right way to block packets from the client as a source...<br>After you connect, do you see the uRPF feature enabled on the Virtual-Access (show run interface and show ip interface)?<br>
<br>Arie<br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 11:35 PM, Frank Bulk <span dir="ltr"><<a href="mailto:frnkblk@iname.com">frnkblk@iname.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is there a way to build an ACL on a Virtual-Access template such that the<br>
connection can only use the IP address given to it by IPCP?<br>
<br>
I applied strict uRPF to the Virtual-Access template, but that didn't stop<br>
this kind of traffic:<br>
<br>
Jan 31 15:23:21 a.b.c.d 38279: Jan 31 15:23:20.964 CST: %SEC-6-IPACCESSLOGP:<br>
list 125 denied udp 80.212.149.228(55190) -> 192.168.0.0(19427), 1 packet<br>
Jan 31 15:23:32 a.b.c.d 38287: Jan 31 15:23:31.476 CST: %SEC-6-IPACCESSLOGP:<br>
list 125 denied tcp 222.172.244.3(2047) -> 192.168.0.0(19427), 1 packet<br>
Jan 31 15:23:33 a.b.c.d 38288: Jan 31 15:23:32.784 CST: %SEC-6-IPACCESSLOGP:<br>
list 125 denied udp 151.48.173.200(25235) -> 192.168.0.0(19427), 1 packet<br>
Jan 31 15:23:36 a.b.c.d 38290: Jan 31 15:23:34.884 CST: %SEC-6-IPACCESSLOGP:<br>
list 125 denied udp 58.108.93.71(13502) -> 192.168.0.0(19427), 1 packet<br>
<br>
Those source IPs aren't mine, and are targeting an RFC1918 address. I'm<br>
blocking traffic originating from my PPPoA/E customers that use a source IP<br>
address outside my netblock or are targeting an RFC198 address using an<br>
inbound ACL on the Virtual-Access template, but it doesn't stop a a customer<br>
from spoofing their neighbor's IP address.<br>
<br>
I've had a basic ACL in place on our internet-facing Ethernet port (Cisco<br>
7206VXR with NPE-400) for a long time, but I didn't having anything in place<br>
to block RFC 1918 addresses. I could have applied the rules to the ACL on<br>
the Ethernet interface, but I've been told to apply an ACL as close as<br>
possible to the source of the traffic.<br>
<br>
To further complicate matters, I also use this router to route RFC 1918<br>
space for corporate needs. I keep that "separate" by using source-based<br>
routing, but that didn't prevent PPPoA/E customers from sending a packet to<br>
the RFC 1918 space, even if the return packet never got back to them.<br>
Perhaps I should use a VRF for handling corporate, traffic, except that I've<br>
never done that before and I would need to spend some time learning.<br>
<br>
Frank<br>
<br>
_______________________________________________<br>
cisco-bba mailing list<br>
<a href="mailto:cisco-bba@puck.nether.net">cisco-bba@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-bba" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-bba</a><br>
</blockquote></div><br></div>