[c-nsp] Handling "junk traffic" with a secondary ISP using NAT

[Ryan West]

Robert,

You might want to look into OER with NAT and leverage application mapping for your outbound selection.  OER can be a bit of a beast, but you might consider.  In a SOHO design, the configuration is a lot less complex.

http://www.cisco.com/en/US/docs/ios/12_4t/oer/configuration/guide/h_oerstr.html#wp1059322

Another choice would application aware PBR, which can also be used with OER or just with source based routing like you listed below.  

I was a little confused by what the /24 statement.  Are you saying that each user has a publicly routed address?  Is your firewall doing NAT?

-ryan


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Robert Johnson
Sent: Monday, August 31, 2009 5:05 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Handling "junk traffic" with a secondary ISP using NAT

Hello Cisco experts,
I have an interesting configuration here. I have an organization with some
/24s of IP space assigned to their internal hosts. The IGP is OSPF and
connectivity to the outside world is via a single ISP with multiple links
using BGP (private ASN). In an effort to cut costs, we would like to use an
additional cheaper consumer-level ISP to handle some of the "junk traffic"
such as streaming radio, MySpace CDN, etc. Traffic that is not mission
critical.

The idea is to add an additional router to the main OSPF area, redistribute
static routes to the "junk traffic" IP blocks into OSPF, and run NAT on the
new router to get all this traffic flowing over the "cheap consumer level
FTTP ISP" connection which is attached to the new router. The configuration
to retract these static routes from the OSPF area upon a failure of the
cheap ISP is straightforward. However, this scheme breaks some
functionality. An incoming connection from a host in one of the "junk
destination" IP blocks to a host in our internal network will flow in
through the normal primary ISP. Responses to this connection, however, will
be routed out through the secondary ISP and NATted, causing the reply
packets to come from a different IP address.

A potential solution would be to have the new router inspect all flows
originating from the internal network and NAT only TCP sessions that
originate from the inside network. The idea was to create a reflexive ACL
containing any TCP flows originating from the inside network that are not
established. Then use PBR to NAT any flows defined in this reflexive ACL,
and send the rest of the traffic out without performing any NAT.
Unfortunately, it doesn't appear to be possible to do this using standard
Cisco reflexive ACLs, since the entries in the reflexive ACL have the source
and destination reversed.

Any ideas to implement this properly?

Thanks,

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