Can't map dhcp leases with mac address on vlan

Started by process, August 31, 2022, 11:18:19 PM

Previous topic - Next topic
August 31, 2022, 11:18:19 PM Last Edit: August 31, 2022, 11:20:44 PM by process
I got a lan 192.168.1.x and a vlan 192.168.10.x. I want to add/force a computer to my vlan by give it an ip of 192.168.10.x from the dhcp leases page or trough the "DHCP Static Mappings for this interface" section.
But I can't get it to work. My computer appears under "dhcp leases" with that ip but if I look on what ip I recieved on the specific computer then it says 192.168.1.x instead of 192.168.10.x
If I try to give my computer a static ip under the lan dhcp then the computer gets exactly the ip I say it should.

First, is it even possible to give a specific computers/units a static ip and force it to be on a vlan trough dhcp leases? Or what am I doing wrong here?

(My purpest for the moment is to have som vlans and try to set up some firewall rules to prevent them for communicate with each other. And I want to try it out and see if it really does work or not, that's why I want to put different computers / vms on different vlans.)

August 31, 2022, 11:55:08 PM #1 Last Edit: August 31, 2022, 11:57:24 PM by meyergru
That is not how VLANs work. You are mixing up different logical layers. Simply put, you cannot control which VLAN a client is on by assigning it an IP address that is associated with a VLAN - that is too late.

Essentially, VLANs are a form of complete separation via different "rails", either by having a network client select its rail itself by static configuration if a physical switch port carries multiple VLANs ("trunk port") or by assigning the switch port to a specific VLAN in the first place. Those decicions are static and take place before DHCP kicks in.

DHCP is handled on a specific VLAN already, so logically, you have one DHCP instance for every VLAN. Theoretically, you could assign every VLAN the same IP range, but those are completely separate networks. The main reason not to do this is that normally, you want to route between the VLAN networks.

The only way to dynamically select a VLAN for a client is using 802.1x or MAC-based VLAN assigment on the switch itself. In that case, the switch can dynamically assign a port to one of the available VLANs.

DHCP has no control there, it simply hands out addresses from IP ranges that are available on specific logical interfaces. Which of those logical interfaces the client connects to is handles way earlier.

Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on August 31, 2022, 11:55:08 PM
That is not how VLANs work. You are mixing up different logical layers. Simply put, you cannot control which VLAN a client is on by assigning it an IP address that is associated with a VLAN - that is too late.

Essentially, VLANs are a form of complete separation via different "rails", either by having a network client select its rail itself by static configuration if a physical switch port carries multiple VLANs ("trunk port") or by assigning the switch port to a specific VLAN in the first place. Those decicions are static and take place before DHCP kicks in.

DHCP is handled on a specific VLAN already, so logically, you have one DHCP instance for every VLAN. Theoretically, you could assign every VLAN the same IP range, but those are completely separate networks. The main reason not to do this is that normally, you want to route between the VLAN networks.

The only way to dynamically select a VLAN for a client is using 802.1x or MAC-based VLAN assigment on the switch itself. In that case, the switch can dynamically assign a port to one of the available VLANs.

DHCP has no control there, it simply hands out addresses from IP ranges that are available on specific logical interfaces. Which of those logical interfaces the client connects to is handles way earlier.

Wow what an answear! It make sense, even though I don't know that mutch about networks yet :)
So a common way to segragate your network with vlan is either trough wireless and in that case using different ssid's to assign them to different vlans?
Or make different ports on the switch to have different vlans? So as an attacker you can basically get full access to the network (if there are a vlan that has that) by more or less trying different ports on the switch? Sounds quite risky on a company network?

September 02, 2022, 11:29:05 AM #3 Last Edit: September 02, 2022, 01:33:46 PM by meyergru
You can do both (or either): on a WLAN, you usually have a 1:1 mapping of WLAN <-> VLAN and secure WLAN access via passwords. If switchports are physically accessible, you have a problem.

Therefore, in a company situation, you usually have important VLANs (like server VLAN) in a closed area like an infrastructure closet - the switch is located there, as well, such that you can only physically access certain ports. But even then, exposed ports in offices are secured by 802.1x or at least by allowing only specific MACs.

The former is used with intelligent clients than can be provisioned with certificates (like PCs), the latter for dumb devices like printers or VoIP phones. Because a MAC can be spoofed, you could have a PC pose as a printer using its MAC (which is commonly visible on a label) - therefore, printers are often on a separate VLAN which has limited access.

As you can see by now, VLANs are a means to separate a network into zones of different sensitivity, but as you said, this works only if you can control this separation - either by separating them on a WLAN level or by making sure that no illicit devices can access privileged ethernet ports. Nowadays, there is also a third kind of networks, i.e. virtual networks. For example, when you have a virtual backup machine for a friend that is accessible from WAN, you want that to be on a separate VLAN (demilitarized zone) that has no access to your LAN.

Following that, you probably have the following VLANs:

- LAN, for your PCs and servers
- IoT (for devices you cannot fully trust, because they might "phone home" and thus introduce security risks)
- Guest (to give friends or neighbors internet access without compromising your own networks)
- DMZ

Between those, you will have limited routing or a firewall which allows access from LAN to all, but little else.
There may be exceptions, like you might allow printing from Guest to printers in IoT. Also, IoT devices can probably access a media share on your LAN (like for your TV to play videos). Guest and DMZ probably also use port isolation, so that devices cannot talk among another.

Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on September 02, 2022, 11:29:05 AM
You can do both (or either): on a WLAN, you usually have a 1:1 mapping of WLAN <-> VLAN and secure WLAN access via passwords. If switchports are physically accessible, you have a problem.

Therefore, in a company situation, you usually have important VLANs (like server VLAN) in a closed area like an infrastructure closet - the switch is located there, as well, such that you can only physically access certain ports. But even then, exposed ports in offices are secured by 802.1x or at least by allowing only specific MACs.

The former is used with intelligent clients than can be provisioned with certificates (like PCs), the latter for dumb devices like printers or VoIP phones. Because a MAC can be spoofed, you could have a PC pose as a printer using its MAC (which is commonly visible on a label) - therefore, printers are often on a separate VLAN which has limited access.

As you can see by now, VLANs are a means to separate a network into zones of different sensitivity, but as you said, this works only if you can control this separation - either by separating them on a WLAN level or by making sure that no illicit devices can access privileged ethernet ports. Nowadays, there is also a third kind of networks, i.e. virtual networks. For example, when you have a virtual backup machine for a friend that is accessible from WAN, you want that to be on a separate VLAN (demilitarized zone) that has no access to your LAN.

Following that, you probably have the following VLANs:

- LAN, for your PCs and servers
- IoT (for devices you cannot fully trust, because they might "phone home" and thus introduce security risks)
- Guest (to give friends or neighbors internet access without compromising your own networks)
- DMZ

Between those, you will have limited routing or a firewall which allows access from LAN to all, but little else.
There may be exceptions, like you might allow printing from Guest to printers in IoT. Also, IoT devices can probably access a media share on your LAN (like for your TV to play videos). Guest and DMZ probably also use port isolation, so that devices cannot talk among another.

Ok I see. My purpose with this was more or less only to try different vlans (with firewall rules) before I went live with my opnsense solution.  That's why it would been easier to have some VM's that you assign to different vlans, so that you easlie could ping the others ip after changing firewall rules.
But is there a simple way to test the vlans if you only have a opnsense solution? or is the easisest solution to add my ubiquiti wifi products and connect to different ssid's (that has diffent vlans underneath) with different computers?

It would been cool if there were som firewall/vlan playground

VMs are very easy to use with VLANs - and they cannot choose to which one they are connected.
You simply setup VLANs, connect the VM host as trunk and create bridges for every VLAN, many of which do not even have an IP address on the VM host itself.

Then, you assign VM guest interfaces to the appropriate bridge.

I helps it you have console access in your VM solution, so that you can check if anything in the networking goes wrong - otherwise you cannot see much. I prefer Proxmox. If you create a lab for testing only, you can also put OpnSense into a VM.

Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on September 05, 2022, 10:42:47 PM
VMs are very easy to use with VLANs - and they cannot choose to which one they are connected.
You simply setup VLANs, connect the VM host as trunk and create bridges for every VLAN, many of which do not even have an IP address on the VM host itself.

Then, you assign VM guest interfaces to the appropriate bridge.

I helps it you have console access in your VM solution, so that you can check if anything in the networking goes wrong - otherwise you cannot see much. I prefer Proxmox. If you create a lab for testing only, you can also put OpnSense into a VM.
Proxmox is something I heard about and will try out later. But for now I only use virtualbox.
I'm really unsure with this as well. But VM host as trunk and create bridges for every lan? Is there some guide to follow along with? Tried to google it but quite hard when you don't know what to begin with. For an example is those bridges for every lan a setting in the network tabs vm or when you running the vm's OS?

It does not matter which way you go, that is a matter of preference. However, assuming that you have a VM host that runs several VM guests which attach to different VLANs, the physical connection that the VM host needs to have a "trunk" access, i.e. all VLANs are accessible, Since many VM guests must attach to the same VLAN, they are usually connected using a logical bridge on the VM host, which in turn connects to a VLAN.

By choosing which host bridge a VM guest connects to you essentially define which VLAN ist is connected to.

Bridging is one type of VM networking which resembles a "switch" in the real world.


Not meaning to be rude, but the questions you ask make me wonder if you really want to start with an advanced networking concept like VLANs without having some basics? If you do not want to read some books about networking, I can recommend NetworkChuck's Youtube channel, which has hands-on examples for many networking concepts you may need along the way.

I think it is easier to build knowledge up from the ground than to start at something exotic and trying to "drill down" to every piece of the puzzle, i.e. instead of being able completing a task building up from existing knowledge, one finds again something that needs to be understood first. The latter way, you will end up in following many branching roots without ever finishing anything before new uncharted territory becomes visible.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on September 07, 2022, 03:50:29 PM
It does not matter which way you go, that is a matter of preference. However, assuming that you have a VM host that runs several VM guests which attach to different VLANs, the physical connection that the VM host needs to have a "trunk" access, i.e. all VLANs are accessible, Since many VM guests must attach to the same VLAN, they are usually connected using a logical bridge on the VM host, which in turn connects to a VLAN.

By choosing which host bridge a VM guest connects to you essentially define which VLAN ist is connected to.

Bridging is one type of VM networking which resembles a "switch" in the real world.


Not meaning to be rude, but the questions you ask make me wonder if you really want to start with an advanced networking concept like VLANs without having some basics? If you do not want to read some books about networking, I can recommend NetworkChuck's Youtube channel, which has hands-on examples for many networking concepts you may need along the way.

I think it is easier to build knowledge up from the ground than to start at something exotic and trying to "drill down" to every piece of the puzzle, i.e. instead of being able completing a task building up from existing knowledge, one finds again something that needs to be understood first. The latter way, you will end up in following many branching roots without ever finishing anything before new uncharted territory becomes visible.

Yes some basic are ofc good. But I think that I need some kind of goal, either like I have now or some tutorial. But this thread went out of topic a lot. So I think it's best that I continue putting the pices toghether by asking new questions, read more and watching stuff.

I seen a lot of network chucks stuff, he's really great. I like lawrence systems as well. But a lot of what I seen is top of the ice berg stuff. Like setting up vlans in pfsense/opnsense. That's what I did as well, but now I need some stuff to be on the vlans. That's why I ended up here ;)

Thanks for your help. If it wasn't for you, I probably still tried to get my computer up on a vlan from the dhcp :)