Private IP vlan interface on public side

[dotnetman]

Hi guys

Hope someone can help me here. Is it a good practice to use a private IP (10.1..) for example interface vlan 10 on the public side of the network for the management of the switch? Basically I have cisco switch that connects the ISP router (public IP) and firewall (public IP), but I am trying to have the switch managed from the internal network. Vlan 10 is a internal routed vlan for the management of other switches. Now I am wondering if setting up a vlan interface with private IP on the external side of the network is secure? And to trunk it back to the internal router bypassing the firewall?
I have set up a different local vlan for the firewall and router and set up ports as "access ports" for that.

Hope it make sense. Thanks for any replies.

 

[bill001g]

It is now dependent on your skill not to misconfiguration switch ports. Generally we look at it as if the most junior guy can screw it up then it is not secure. A firewall tends to have must more protection against stupid configurations. Years ago this was a huge issue when cisco switches had a bug that let you inject a tagged packet on a access port. It still can be done in some q in q configurations. HP procurve also used to process packets for vlans that were not assigned to the port. Those holes have all been closed but a switch does not go though the same security hardness testing that a firewall product does.

Normally you put in a jump server of some form in the outside network that you do all your work from. You either pass it though the main firewall or you put in another small firewall whose only purpose it to talk to that one server and only allow traffic outbound to that server.

 

[dotnetman]

It is now dependent on your skill not to misconfiguration switch ports. Generally we look at it as if the most junior guy can screw it up then it is not secure. A firewall tends to have must more protection against stupid configurations. Years ago this was a huge issue when cisco switches had a bug that let you inject a tagged packet on a access port. It still can be done in some q in q configurations. HP procurve also used to process packets for vlans that were not assigned to the port. Those holes have all been closed but a switch does not go though the same security hardness testing that a firewall product does.

Normally you put in a jump server of some form in the outside network that you do all your work from. You either pass it though the main firewall or you put in another small firewall whose only purpose it to talk to that one server and only allow traffic outbound to that server.

Thanks for the quick response. However I was more concerned about having the private internally routed vlan interface on the outside. Is there a solution for switch management for this sort of scenario?

 

[bill001g]

It isn't routed and can't really be routed on the outside. You can make it work on your local equipment but any ISP who has clue will filter discard all packets that are sourced from a rfc1918 address. It should hurt nothing because no machine on the outside "should" directly be able to to talk to those address.

Many commercial switches are starting to come with special management ports that can only be used to access the switch itself and no the data flowing though it. You can of course use a small console server and use the console port on the switch but there some things you cannot get via the console port link SNMP and such