First; network is not my thing but still im here.
My router is : RB5009UPr+s+IN
I have a proxmox-server connected on ether4 on the router with IP 192.168.88.X. Now i want to do clever stuff and create a VLAN for the my VMs that uses 10.0.10.0/24.
I created everything with following script:
/interface vlan
add name=vlan10 interface=ether4 vlan-id=10
/ip address
add address=10.0.10.1/24 interface=vlan10 network=10.0.10.0
# I know; not necessary if i use static ip's
/ip pool
add name=dhcp_pool_vlan10 ranges=10.0.10.10-10.0.10.100
/ip dhcp-server
add name=dhcp_vlan10 interface=vlan10 address-pool=dhcp_pool_vlan10 disabled=no
/ip dhcp-server network
add address=10.0.10.0/24 gateway=10.0.10.1 dns-server=10.0.10.1
/ip settings
set accept-source-route=no accept-redirects=no
/ip firewall filter
add chain=forward action=accept src-address=192.168.88.0/24 dst-address=10.0.10.0/24 comment="Allow LAN to VLAN10"
add chain=forward action=accept src-address=10.0.10.0/24 dst-address=192.168.88.0/24 comment="Allow VLAN10 to LAN"
Everything works fine except when i want to make DNS lookups from 10.0.10.100 (think: dig @10.0.10.1google.com)
From 10.0.10.100 I can ping 10.0.10.1 and 192.168.88.1. Making dig with 8.8.8.8 also works.
If I trying the same thing from a server that I have on 192.168.88.0/24 everything works fine.
What can be wrong here? Is it all wrong? Do you understand even what i’m trying to do? Im not sure that I have the knowledge to answer any follow-up questions
You are having firewall troubles. The problem is that you are giving out the router as being the DNS server, however the DNS requests hit the input firewall chain, not forward, and there you have made no provision to allow this traffic. Do so and your troubles will be gone
If you are making your config based on the default firewall settings, the easiest way to accommodate your new VLAN interface in the firewall rules is simple to add it to the LAN interface list. In this case no new rules (either input, or the ones you added to forward) are necessary.
I would had believe this vlan to able to be compliant with dns remote request. But they are blocked. My solution was to add a vlan interface to the bride and add it to the LAN interface list
/interface vlan
add interface=bridge name=bridge-vlan2-VoIP vlan-id=2
/interface list
add name=WAN
add name=LAN
/interface list member
add interface=pppoe-out1 list=WAN
add interface=bridge list=LAN
add interface=bridge-vlan2-VoIP list=LAN
Still, I thought all VLANs, in this bridge, woud automatically be in the LAN and not be drop by this default input rule.
I think that we can say that ethernet interfaces, once added to a bridge, are “inside” the bridge (hence you add the bridge to the LAN list and not the single interfaces, that become part of the bridge), but VLAN interfaces “sit on top” of the bridge, so you have to add the actual VLAN interface to the LAN list as a separate item, or if you prefer it is a further layer around the bridge that keeps however its own dignity (unlike ethernet interfaces that are assimilated into the bridge).
Well, you thought wrong, but good on you, now you think right In fact your fix is exactly the appropriate one.
This seems to come up a lot lately, so a better explanation is in order. Separating things into VLANs is done exactly in order to have separate interfaces available. This is suitable for assigning different networks, different routing, different DHCP servers and this includes different firewall rules.
Once you deploy vlans, in routed scenarios, vlan interfaces have to be added, and from then on, these will be the ingress/egress interfaces.
In order to diagnose such issues, the very useful bult-in feature is simply logging firewall rules. If you were to incorporate, temporarily, a rule like this
then you’ll see log entries for each incoming DNS packet, which will identify the input interface as you vlan interface.
When applying this rule, put it first in the input chain. This rule (action=passthrough) doesn’t affect packet processing other than logging and counting them.
More clearly stated by a non IT trained person
Do not use bridge to do any subnet work after going vlans. It shall only do simple bridging.
Simply call the previously associated subnet,. another vlan on the bridge vlan-bridge for example ( pvid-11).
The bridge is no longer listed on the interface list for anything and the vlans are listed as being LAN members.
With clear direction you will be now called happystick
I’ll put it in a yet another way: (L3) interface is the entity which has IP/IPv6 address assigned …
It can be ethernet interface if that one is not used as bridge port (in default config on nany devices it’s how ether1 is used) … it can be bridge interface if VLANs are not used … and it can be vlan interface when VLANs are used (and it doesn’t matter which port serves as vlan interface anchor, can be either physical port or cpu-facing bridge port). Or it can be some tunneling interface, such as pppoe interface.
And no, this status (being interface rather than port) doesn’t get “inherited” from “parent” interface/port.
N.b.: almost any entity (apart from vlan interfaces and some tunneling interfaces) can be port and interface at the same time if used as “hybrid port” … port as anchor for vlan interface and interface for untagged traffic. But this kind of hybrid personality can make understanding more complex as @anav already mentioned.
I have no heartache with hybrid ports on a bridge either, what I am saying is that for the vast majority of home and even soho networks, there is no need to mix bridge with subnet when using vlans for subnets.
There is also nothing wrong with assigning an interface its own IP address with that interface not being on the bridge ( heck its my go to for configuring vlan filtering anyway for example ), or even using two bridges etc…
In fact your fix is exactly the appropriate one.
