today I will talk about how you can separate the management vlan from the routing table.
Ok that sounds interesting but why do you want that?
In this scenario, I use an HPE Comware 5900 as a central core switch that routes between the individual VLANs. This means that the switch needs an IP address for each VLAN and can be addressed via this address.
And in addition, the requirement was that the management traffic be routed through a firewall to scan the data stream and block it if necessary.
Now comes the exciting part: Because the switch routes in the network, the management VLAN is accessible from all other networks and routes past the firewall directly into the management VLAN.
This also applies to the Out of Band Management Interface.
seperate the management vlan
To separate the management vlan or the OOBM interface from the routing table, we have to put it into a separate VPN instance.
this can be done with the following commands:
system view ip vpn-instance Management interface Vlan-interface666 description Management-VLAN ip binding vpn-instance Management ip address 10.69.69.2 255.255.255.0 quit ip route-static vpn-instance Management 0.0.0.0 0 10.69.69.1 s s f
If we now run a dis ip routing-table, we see that the management vlan is no longer included. And because we have a default route to the firewall, the management traffic is routed through the firewall.
For control you can you enter dis ip routing-table vpn-instance Management to see the additional routing table also with its own default route for the vpn instance.
Securing the remaining VLAN interfaces
OK, the management vlan is now protected by the firewall, but the switch can be reached via all other IP addresses four SSH, HTTPS or similar. Therefore, we now have to create a very very long advanced ACL that contains every IP of the switch. Except for the IP of the management vlan, otherwise no one can access it remotely 😀 Here it is important to specify only the individual IP of the switch. If you simply block ssh and co for 192.168.0.0/16, all other systems that fall under this IP range will also be affected.
ACL example for 2 VLANs
acl advanced name NoManagementAccess rule 0 deny tcp destination 10.16.55.1 0 destination-port eq 22 rule 1 deny udp destination 10.16.55.1 0 destination-port eq 22 rule 2 deny tcp destination 10.16.55.1 0 destination-port eq 80 rule 3 deny tcp destination 10.16.55.1 0 destination-port eq 443 rule 10 deny tcp destination 10.18.69.1 0 destination-port eq 22 rule 11 deny udp destination 10.18.69.1 0 destination-port eq 22 rule 12 deny tcp destination 10.18.69.1 0 destination-port eq 80 rule 13 deny tcp destination 10.18.69.1 0 destination-port eq 443 quit ssf
Now the ACL must be bound to each VLAN interface for incoming traffic.
interface Vlan-interface100 ip address 10.16.55.1 255.255.255.0 packet-filter name NoManagementAccess inbound dhcp select relay dhcp relay server-address 192.168.0.66 dhcp relay server-address 192.168.0.67 interface Vlan-interface101 ip address 10.18.69.1 255.255.255.0 packet-filter name NoManagementAccess inbound dhcp select relay dhcp relay server-address 192.168.0.66 dhcp relay server-address 192.168.0.67 quit ssf
The what, now the management interfaces of the core switch are only accessible via the firewall exclusively under the management vlan ip.
You don’t have to change anything for the edge switches, because they only have one IP from the management VLAN and then route via the firewall anyway.
Have a nice day!