Re: Finding asymmetric path

["Brielle Bruns" <bruns () 2mbit com>]

(Forgive the top posting, stupid blackberry can't do inline)

A creative idea that I did in a test lab one time - stateful connection tracking, its not just for NAT you know.

Would require a bit of moving stuff around and reengineering of your connection to them, but it would cripple their 
connection unless it originated through you.

IE: 

You <-> UNIX/Linux firewall <-> T1/eth/dsl/etc

If stuff went out the other way, it would come in, firewall says WTF, and drops it because it didn't see the initial 
SYN exchange.

My partner Tammy says a PIX could probably accomplish the same task (we have some here for the corp lan stuff, 
including spares).


Brielle
-- 
Brielle Bruns
http://www.sosdg.org  /  http://www.ahbl.org

-----Original Message-----
From: ML <ml () kenweb org>
Date: Sat, 28 Nov 2009 14:14:07 
To: nanog () nanog org<nanog () nanog org>
Subject: Re: Finding asymmetric path

Brielle Bruns wrote:
> On 11/27/09 8:43 PM, ML wrote:
> > I'm reasonable certain a customer of ours who is using one of our
> > netblocks is using a different reverse path to reach us. How might I
> > figure out who is allowing them to source traffic from IPs that belong
> > to us?
>
> I've had two customers pull this stunt in the past with me - one, a 
> spammer, tried to do this with an ADSL modem from me, the other (a 
> non-spammer with a clueless 'consultant') had a T1 from me and a T1 from 
> UUNet.
>
> It started with the T1 customer.  I believe they had a smaller block of 
> IPs (less then /24, more like a /25 or /26), and their 'computer 
> consultant' with his infinite wisdom decided to send all outbound 
> traffic through the UUNet T1 rather then source routing which we highly 
> recommended to them.  Of course, we had ingress filters in place to 
> block IP ranges we have from coming into us from the WAN links, so when 
> they tried to contact servers on the other half of the netblock on our 
> end, the connections mysteriously failed.  After lying up and down that 
> it was our fault, that their computer 'consultant' was regarded as best 
> in the country, blah blah blah, we flipped on logging on the ingress 
> filters out of sheer curiosity and discovered exactly what was going on.
>
> The ADSL customer was a bit more tricky - we were getting spam reports 
> about his single IP address sending spam, but we had his outbound port 
> 25 blocked.  Ended up sniffing the port off the router he sat off of, 
> and discovering that it was all one sided, wasn't even tickling the 
> ingress filters.
>
> Hey, at least your customer didn't convince AT&T to allow them to 
> announce out one of your /24s when all they had was a /29.
>
> Your in a tricky bind, I'd approach them under the guise of ingress 
> filtering issues.

Brielle is correct.  The customer in question is spamming networks and 
we are having trouble filtering them because another provider allows 
them to source traffic however they please.

Of course the other provider seems to be a spam friendly upstream. 
Hopefully you can understand why I'm not hopeful of getting anywhere 
with them either.