LAN subnet dst address not staying in core

[Jason Fraioli]

greetings,

My LAN requires that some users have the ability to routinely reconfigure their IP addresses for whatever project they are working on. Normally this isn't a problem because if they need access to specific network resources or the internet, they will reconfigure back to the IP's that the admins issued to them originally.

The problem is that when these users create their own subnet out of thin air, I get a ton of firewall logs indicating that their private subnet has been dropped. The reason being is that my core doesn't have a route or subnet setup for the one they created, and thus has been sent up to the firewall via the default route.

This results in having a legitimate LAN address trying to find another legitimate LAN address outside of my core.

Furthermore, how is it possible that in a VLAN, collapsed core architecture, a user can create a subnet out of thin air, and communicate outside of the switch he is directly connected to? I assume that my access layer switches are trunking that IP up to the core which is looking for a destination vlan to forward to. It can't find a VLAN matching the destination address so it forwards via the default route. Is that the case and is there anyway to prevent that behavior such that only subnet traffic "assigned" to that VLAN can communicate on said VLAN?

[Jon Marshall]

Jason

It's not entirely clear how this works in your environment. The user can change their IP address but unless they can change the vlan the switch port is in the IP address would need to be out of the same range wouldn't it ? eg

the admin assigned IP address is 192.168.5.10 255.255.255.0 and that is vlan 10 so the switchport the user is connected into is assigned to vlan 10. In your core you have a L3 SVI for vlan 10 with IP address 192.168.5.1.

User changes IP address to 192.168.10.10 255.255.255.0. But the switch port is still in vlan 10 so how do any packets get routed to your core and back again ?

Unless of course the ports are all in vlan 1 - then you can see some funny things happen. Do you know which vlans the ports are assigned to ?

Jon

[Jason Fraioli]

I have only one core, and all VLAN subnet routes are directly connected.

if a user in the 192.168.5.0 (vlan 5 which has a L3 SVI on the core) attempts to connect to 192.168.6.0 (not configured as a vlan and no L3 SVI), I will see a firewall log entry stating that;

192.168.5.x was denied trying to connect to 192.168.6.x

If 192.168.6.0 does not exist as a VLAN, and has no L3 SVI, is it safe to assume that this 192.168.6.0 address space is being routed by my core's default route to my firewall?

[tdrais]

When I first read this I though this was a issue with them spoofing the source address.

You are going to see this problem in any network. You will of course see more when someone is trying to really use a unknown address in your network.

To kill all private and not let them go to your firewall just put a null0 summary like

ip route 10.0.0.0 255.0.0.0 null0

in your core. Your core will then discard them rather than the firewall.

If all your l3 switches contain a full routing table of all your valid private address you can put this all devices to drop it as close to the edge as possible but it is simpler to manage if it is only in the core.

[Richard Burts · Accepted solution]

Jason

I believe that it is very safe to assume that the address space was being routed by your core to your firewall.

If you want to prevent this symptom one alternative would be to do reverse path check on the SVIs - ip verify unicast reverse-path. This would prevent the packet getting past the SVI and the firewall would not see it.

I am a bit puzzled why people would invent addresses and subnets like that. It seems to me that since the core has no way to route any response/return traffic that the device would lose its network connectivity and functionality. Is there some aspect of this situation that we do not understand yet?

HTH

Rick

[Jason Fraioli]

Rick, yes there is, but it is irrelevent to the conversation. The addresses/subnets they invent are not part of the enterprise network in any way. The problem is when they attempt to re-join the enterprise network without forst re-setting their IP back to normal.

Thanks for the reverse-path verification, although I do have one questions about it.

I assume that it will prevent an address from going beyond the SVI if the SVI cannot route back to the host. This assumes that I have a misconfigured host.

What about if the source address is valid, but the destination address (also a LAN address) is not valid? Would I then have to use tdrais's approach and route those destination subnets to Null0?

Edit: Is it a best practice to put the verify reverse path command on the routed port heading to the firewall or should that really be done on the SVI's?

Edit2: Would enabling verify reverse path be the same as creating an ACL that drops specific address space, or subnets not in the routing table?

[Richard Burts]

Jason

My suggestion for using reverse path check will deal with issues of source address. For issues with destination address the suggestion from tdrais of configuring a summary address to null 0 is the most effective solution.

edit1: it should be done on the SVI.

edit2: reverse path check is a bit different from creating an access list, and it is not just checking that the source address is not known in the routing table. What it does is to look at the source address of packets arriving on the interface and if that interface is not a valid way to get to the subnet of the sourece address then the packet is invalid and is dropped.

I am glad that our responses were helpful in resolving your questions. Thank you for using the rating system to indicate that your question was resolved (and thanks for the rating). It makes the forum more useful when people can read a question and can know that there were responses which helped to resolve the question.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick