<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>Just to add to that, is there a way that the Virtual-interface that’s
doing the spoofing can be identified? The log entries for the ACL hits
don’t show anything but the spoofed IP, but I don’t know which
connection is doing it. Perhaps it’s one PPPoA/E connection that’s
generating those spoofed packets…<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>Frank<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Arie Vayner
[mailto:arievayner@gmail.com] <br>
<b>Sent:</b> Saturday, January 31, 2009 3:49 PM<br>
<b>To:</b> Frank Bulk<br>
<b>Cc:</b> cisco-bba@puck.nether.net<br>
<b>Subject:</b> Re: [cisco-bba] ACLs on Virtual-Access templates<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>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<o:p></o:p></p>
<div>
<p class=MsoNormal>On Sat, Jan 31, 2009 at 11:35 PM, Frank Bulk <<a
href="mailto:frnkblk@iname.com">frnkblk@iname.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>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><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>