Cookie-Cutter Networks with Duplicate IP Ranges

Otanx · August 29, 2019, 02:07:40 PM

Cloud AI is just someone else's ~~computer~~ brain.

-Otanx

deanwebb · September 12, 2019, 03:20:44 PM

Update... found a customer network where, somehow, devices with 192.168 addresses were gettin' around. Customer was supposed to only be using addresses in the 10 range, but we just discovered a writhing mass of home devices, with traffic routing around on the internal network.

Where are the devices? Hard to say, since so many have duplicate addresses...

Dieselboy · September 12, 2019, 11:36:50 PM

Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again

deanwebb · September 13, 2019, 01:46:28 PM

Quote from: Dieselboy on September 12, 2019, 11:36:50 PM
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again

That was my recommendation, since the whole environment was constantly in flux.

Otanx · September 16, 2019, 08:36:09 AM

Quote from: Dieselboy on September 12, 2019, 11:36:50 PM
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again

We do this with all RFC1918 space, and bogon stuff. We have a pair of Quagga servers that peer with all our edge devices, and hand out those, and any malicious IPs supplied by our cyber team.

-Otanx

icecream-guy · September 16, 2019, 11:05:58 AM

Quote from: Otanx on September 16, 2019, 08:36:09 AM
Quote from: Dieselboy on September 12, 2019, 11:36:50 PM
Easy. Configure the customers edge with routes to `null0` for the other networks that are outside of the customers 10.x.x.x range. Then go pull yourself a beer, safe in the knowledge your customer is secure once again

We do this with all RFC1918 space, and bogon stuff. We have a pair of Quagga servers that peer with all our edge devices, and hand out those, and any malicious IPs supplied by our cyber team.

-Otanx

Thought Bogons were a thing of the past, at least for IPv4, since all the IP space is now exhausted.
Still got to check for Martians.

Otanx · September 16, 2019, 04:53:54 PM

I guess it depends on how you define Bogons vs Martians. I had to look it up. Team Cymru (who I kind of see as the experts) list Bogons as including all Martians plus unallocated space. So Martians are a type of Bogon address. However, other references I found flip that and say Bogons are just the unallocated space, and that Bogons are a type of Martian. However, I will say I have not heard of anyone calling these Martian filters even if that is what they are.

To be more specific we include all RFC 1918, CGNat, and all the other IPs from different RFCs that should not be on the internet. We also filter out all "Class D" and above. Multicast shouldn't be hitting our edge. Also 127.0.0.0/16. We also have uRPF configured so the filters will drop traffic with those as source addresses as well. This lets us detect mis-configurations on our gear (wrong NAT statements usually), and/or weird traffic from the internet like someone trying to DoS us with a source of 127.0.0.1.

-Otanx

Dieselboy · September 16, 2019, 09:08:26 PM

Nice!

I have configured firepower to do something similar but it's about time for me to go and eval the config and tweak.

On the edge routers/ASAs I do this:

Code Select

route Null0 10.0.0.0 255.0.0.0 254
route Null0 172.16.0.0 255.240.0.0 254
route Null0 192.168.0.0 255.255.0.0 254

I took that from Cisco's config guide for VTI tunnel IPSEC. The guide said to do that so when the VTI tunnel is down, the ASA does not just send the traffic out to the internet unencrypted 🙈 I Thought "yea good point"

deanwebb · September 17, 2019, 08:37:41 AM

This is some great tips and info in this thread. Basically, a panel discussion on how to deal with IP ranges that devices and/or users bring with them to your network.

Otanx · September 17, 2019, 08:47:50 AM

Quote from: Dieselboy on September 16, 2019, 09:08:26 PM
Nice!

I have configured firepower to do something similar but it's about time for me to go and eval the config and tweak.

On the edge routers/ASAs I do this:
Code Select Expand
route Null0 10.0.0.0 255.0.0.0 254 route Null0 172.16.0.0 255.240.0.0 254 route Null0 192.168.0.0 255.255.0.0 254

I took that from Cisco's config guide for VTI tunnel IPSEC. The guide said to do that so when the VTI tunnel is down, the ASA does not just send the traffic out to the internet unencrypted 🙈 I Thought "yea good point"

Yep that is basically what happened to us, but on a DMVPN router. We fixed it by using a VRF for the internet facing interfaces, and then added the drops as a way to alert.

Because you brought it up. One other place I have seen the duplicate IP issue is with IPSec tunnels. The VTI needs a /30 for the tunnel. You don't really use these IPs for anything except next hops. A lot of people I have had to deal with like using RFC1918 space for this. The problem is trying to de-conflict address space not just between us and them, but us, them, and all the other "thems" we have tunnels with. We force using public space for that now (and /31 if possible).

-Otanx