Setting up VLAN with Secondary Address on eth 0/1

[shdawson]

Hi

I have set up a 3120 for a local business office. Office staff are currently using the default VLAN 1 to perform administrative and financial transactions, connecting to the remote HQ via SSL. At the same time, visitors to the offices are also using VLAN 1 to connect to the Internet. The business have asked me to segment the network into separate VLANs, to completely isolate all the office staff usage of the network from the visitor's traffic, as they have the option to use free Internet access.

The business has a block of public IP addresses, served by a cable modem. The 3120 is manually configured to use one of these IP addresses on eth0/1. I have also connected a switch on port 3 of the NetVanta, which in turn connects to other multiple switches to serve the offices and the visitor area. Currently all of these switches are running within the default VLAN 1.

I thought of adding a secondary public IP address to eth0/1 to be used exclusively by office staff for connecting to the remote HQ and doing any other Internet work. This will be useful if the HQ decide to set up a VPN to secure traffic with the local office, or constrain incoming and outgoing traffic with the local office using firewall rules.

I plan to set up a separate VLAN for office staff (VLAN 😎 to achieve network isolation between the two user groups within the LAN and also use it to route packets from/to the secondary IP address. The visitors can continue to use the default VLAN 1.

Since this is a production network, I can only take down the 3120 for short periods of time, ideally for no longer than a reboot. I would appreciate if you could point at any errors or omissions in the attached config file, before I run it on the live system.

Thanks,

SHD

[Anonymous]

Some of it will work, but some will not.  99.99.99.333 is an invalid IP address, so that part of the configuration will not be loaded into running configuration and ETH 0/1 will not have the secondary IP address.

I also think it would be a better practice to put the vlan 8 interface/segment in it's own policy-class.  You can still allow the two network to access each other, but programming will be a lot cleaner and easy to troubleshoot. 

Look at this as an option for part of the programming:

!

interface eth 0/1

  description Business_Name

  ip address  99.99.99.222  255.255.255.248

  ip address  99.99.99.223  255.255.255.248  secondary

  ip access-policy Public

  no shutdown

  no lldp send-and-receive

!

interface vlan 8

  ip address  172.16.1.1  255.255.255.0

  ip access-policy Private2

  ip policy route-map Office-Route

  name "Office VLAN"

.

.

.

!

ip policy-class Private

  discard list Switches policy Public

  discard list Printers policy Public

  allow list self self

  nat source list wizard-ics address 99.99.99.222 overload policy Public

!

!

ip policy-class Private2

  discard list Switches policy Public

  discard list Printers policy Public

  allow list self self

  nat source list wizard-ics address 99.99.99.223 overload policy Public

!

[shdawson]

Thank you, much appreciated.

PUBLIC IP:

Yes, you are correct. The config has fabricated addresses, for confidentiality, though they are a contiguous bock from the ISP. The setup is:

99.99.99.221 for the modem,

99.99.99.222 for the primary public IP, and

99.99.99.223 for the secondary.

COMMENTS and QUESTIONS:

You statement about a separate 'Private 2' APC for the VLAN 8 interface makes sense. Only packets sent out through VLAN 8 will be processed by it and therefore they won't need to be separated by convoluted multi-stage set up, with stateless filters and what not, to effect isolation between the two VLANs and two public IP addresses.

However, noticed you left in VLAN 8 the route-map policy:

ip policy route-map Office-Route

If we were to keep this and match the two Office PCs, guessing this will now become:

route-map Office-Route permit 10

match ip address 172.16.1.2

match ip address 172.16.1.3

set ip next-hop 99.99.99.221 255.255.255.248

...which implies that a 'no rpf-check' statement will still be necessary for VLAN 8 PCs at the Public interface to avoid the firewall blocking ingress, since the packets going out of VLAN 8 will not be following the default Public route table. Therefore, can't see how the above will work with his 'list wizard-ics' suggestion under 'Private 2' APC, unless the Public policies change too.

Finally, the statement "you can still allow the two network to access each other" is confusing. We want to achieve the exact opposite: to completely isolate VLAN 1 from VLAN 8 and ensure ingress and egress for VLAN 8 happens exclusively via the secondary IP address

99.99.99.223, while VLAN 1 continues to use 99.99.99.222.

Or, is this going to happen as you stated and there is a lack of understanding on our part here? Specifically, will your suggestion:

a) definitely block interVLAN communication, which is our desired goal;

b) retain egress and ingress for VLAN 8 PCs via the secondary public IP

address only; and

c) what should the Public policies look like, given the point above about VLAN

8's route-map and need for a 'no rpf-check'.

Thank you, again.

[shdawson]

Still trying to complete the Public ACP configuration.

-SHD

[Anonymous]

shdawson‌:

The application you described is common.  The way vmaxdawg05‌ described it is a good network design.  If you have multiple VLANs and policy-classes for the LAN, when you specify the outbound policy on the NAT statement, this will prevent the VLANs from communicating with each other, but still allow them to access the Internet (which is your goal).  I do not see a reason for a route-map, nor multiple public facing policy-classes based on your description.

I hope that makes sense, but please do not hesitate to reply to this post with any additional questions.  I will be happy to help in any way I can.

Levi