This is my first MikroTik device, so I’m sure I’m getting something obvious wrong here. I think the setup I’m going for is quite simple:
ether1: WAN
ether4: management (dhcp client)
ether5: vlan99 (dhcp server)
This is on a hEX S, and I’ve got the following config:
# nov/11/2025 17:13:28 by RouterOS 6.49.19
# model = RB760iGS
/interface bridge
add frame-types=admit-only-vlan-tagged name=br1 vlan-filtering=yes
/interface vlan
add interface=ether5 name=vlan99 vlan-id=99
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp-vlan99 ranges=10.19.99.51-10.19.99.100
/ip dhcp-server
add address-pool=dhcp-vlan99 disabled=no interface=vlan99 name=dhcp99
/interface bridge port
add bridge=br1 frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether5 pvid=99
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface bridge vlan
add bridge=br1 tagged=br1 vlan-ids=99
/interface list member
add interface=ether1 list=WAN
add interface=vlan99 list=LAN
add interface=ether4 list=LAN
/ip address
add address=10.19.99.1/24 interface=vlan99 network=10.19.99.0
/ip dhcp-client
add disabled=no interface=ether1
add disabled=no interface=ether4
/ip dhcp-server network
add address=10.19.99.0/24 dns-server=1.1.1.1 gateway=10.19.99.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked log-prefix=in1
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="accept on vlan99" in-interface=vlan99 log-prefix=in-vlan
add action=accept chain=input comment="accept on ether4" in-interface=ether4 log-prefix=in-ether4
add action=accept chain=forward comment="defconf: accept out ipsec policy" disabled=yes ipsec-policy=out,ipsec
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log-prefix=in-notlan
add action=drop chain=input comment="catchall input drop"
add action=accept chain=forward comment="defconf: accept in ipsec policy" disabled=yes ipsec-policy=in,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked log-prefix=in-end
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="Allow vlan99 internet" connection-state=new in-interface=vlan99 out-interface-list=WAN
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="catchall forward drop"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/system clock
set time-zone-name=America/Los_Angeles
/system identity
set name=RouterOS
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
I cannot, for the life of me, figure out why vlan99 doesn’t get internet access. With multiple clients connected, they can reach each other as well as the gateway, but none of them can reach the internet.
I originally did not even have a bridge in this configuration, I figured that would be fine since I am only interested in one port, really. I’ve added the bridge out of desperation (every similar setup I could find online had a bridge), but to no avail.
I was pretty suspicious of the firewall but based on the packet count for each rule as well as from some log inspection, it doesn’t seem like any of these rules are getting hit when I ping 1.1.1.1 from any of the clients.
Not related to your issue, but once you've got it working, if those are the only ports you are using (ether1, ether4, ether5) then consider putting vlan99 on ether2 instead.
So that ether1 and vlan99 don't have to share the same 1Gbps link to the CPU.
Can you verify if the router itself has internet connectivity? Try to run this in the Terminal:
/ping [:resolve mikrotik.com] count=5
Does /ip route print show the correct default route (destination 0.0.0.0/0) with expected gateway (an address in the range of the subnet the DHCP server advertises on ether1) in the active state?
And if you go to one of the client devices in vlan99 and run a tracert / traceroute / tracepath (depends on the client OS) to 8.8.8.8 does it work and is the first hop the router's address at 10.19.99.1?
Could you please elaborate? Which line should I be disabling, and why? Surely not the first one, since that’s the connection to the ISP. I’m currently using the second one for management, it would be really unfortunate to have to disable it. Why do you suspect this is problematic?
How is you client device (that you are testing from) plugged into ether5? Do you have a managed switch in between and did you properly configure VLAN on that switch.
If you plug your computer directly into that ether5 port (no switch) then you'll need to configure a VLAN interface on that machine.
If using Linux, try traceroute with -I so that it uses ICMP. Also print your computer's route table with ip route.
I have tested both cases. Currently, I have a managed switch in between with the relevant port set to allow all vlans. Crucially, I believe this part is working because with an interface configured for this vlan (ens19), I get a dhcp reservation from the mikrotik router.
I did also test with my laptop directly connected to ether5 as well (with the vlan configured on the interface) and saw exactly the same behavior.
-I unfortunately did not have any impact.
IP route:
> ip route
default via 10.19.21.1 dev ens18 proto static
default dev veth69a9f47 scope link src 169.254.239.74 metric 1001059
10.19.21.0/24 dev ens18 proto kernel scope link src 10.19.21.24
10.19.21.1 dev ens18 proto static scope link
10.19.50.0/24 dev ens20 proto kernel scope link src 10.19.50.24
10.19.99.0/24 dev ens19 proto kernel scope link src 10.19.99.24
10.19.99.1 dev ens19 scope link
169.254.0.0/16 dev veth69a9f47 scope link src 169.254.239.74 metric 1059
192.172.0.0/24 dev docker0 proto kernel scope link src 192.172.0.1 linkdown
192.172.1.0/24 dev br-95de66647c24 proto kernel scope link src 192.172.1.1
I tried both with and without the 10.19.99.1 route, no change either way
From the content of your route table, there is no default route added by DHCP for gateway 10.19.99.1. Only the default route that you configured on ens18, which as I can see is your management subnet that ether4 of the router is also connected to.
Are you sure that 10.19.99.24 is assigned to the Linux device by DHCP? Verify with ip addr whether that address entry is listed as dynamic or not.
I see no static leases configured on the RouterOS DHCP server, which means it's a strange coincidence that the RouterOS DHCP server allocates 10.19.99.24 to your Linux computer, the exact same .24 ending that you pick for 10.19.21.24 on ens18. Maybe you've statically configured the 10.19.99.24 address beforehand but have forgotten about it?
Yes, sorry about that. This server was configured with a static IP, however, I have another server which is configured nearly identically and is the one that successfully received the DHCP reservation from the router. The above tests all behave exactly the same way on that server, but here’s the routing table for reference:
> ip route
default via 10.19.21.1 dev ens18 proto static
default via 10.19.99.1 dev ens19 proto dhcp src 10.19.99.100 metric 1047
10.19.21.0/24 dev ens18 proto kernel scope link src 10.19.21.18
10.19.21.1 dev ens18 proto static scope link
10.19.99.0/24 dev ens19 proto dhcp scope link src 10.19.99.100 metric 1047
169.254.0.0/16 dev vethbfa6a24 scope link src 169.254.194.123 metric 1014
169.254.0.0/16 dev veth0488e3b scope link src 169.254.125.66 metric 1016
169.254.0.0/16 dev veth48fb294 scope link src 169.254.54.69 metric 1018
169.254.0.0/16 dev veth7ed53de scope link src 169.254.36.107 metric 1020
169.254.0.0/16 dev veth05ee5b6 scope link src 169.254.48.36 metric 1024
169.254.0.0/16 dev veth1ecd868 scope link src 169.254.75.224 metric 1026
169.254.0.0/16 dev veth4706849 scope link src 169.254.245.42 metric 1028
169.254.0.0/16 dev vethe13c903 scope link src 169.254.191.186 metric 1044
169.254.0.0/16 dev veth16dbc70 scope link src 169.254.218.134 metric 1046
169.254.0.0/16 dev ens20 scope link src 169.254.50.193 metric 1049
169.254.0.0/16 dev vethfc15a8f scope link src 169.254.225.177 metric 1052
169.254.0.0/16 dev veth402b173 scope link src 169.254.106.195 metric 1054
192.172.0.0/24 dev docker0 proto kernel scope link src 192.172.0.1 linkdown
192.172.1.0/24 dev br-62ddc1d1645a proto kernel scope link src 192.172.1.1
192.172.2.0/24 dev br-298de509304f proto kernel scope link src 192.172.2.1
192.172.3.0/24 dev br-e011df9f205c proto kernel scope link src 192.172.3.1
192.172.4.0/24 dev br-062cbed197df proto kernel scope link src 192.172.4.1
192.172.5.0/24 dev br-a4eae3114a3c proto kernel scope link src 192.172.5.1
192.172.6.0/24 dev br-a98fc9aefd5b proto kernel scope link src 192.172.6.1 linkdown
192.172.7.0/24 dev br-287c86c498d6 proto kernel scope link src 192.172.7.1 linkdown
192.172.8.0/24 dev br-a0b85fad4901 proto kernel scope link src 192.172.8.1
192.172.9.0/24 dev br-fa0b558715ac proto kernel scope link src 192.172.9.1
as you can see, the default route is added in this case, however, I still cannot reach the internet from this box.
And pinging 10.19.99.1 from that computer does not work at all? If that's the case, maybe verify the firewall configuration on that machine?
If ping is possible, then can you modify the static setting on ens18 and set the metric of the corresponding default route to 2000 or so (higher than 1047). Or disable the default route on that interface since it's supposed to only be used for management? Currently that default route has a metric of 0 and will win over the one via 10.19.99.1 with metric 1047.
Both servers can ping 10.19.99.1 as well as ping each other at 10.19.99.100 and 10.19.99.24
I can’t easily modify the metrics on the routes since they’re assigned by dhcp, but I tried adding a new default route: sudo ip route add 0.0.0.0/24 dev ens19 metric 1040, no luck with that either.
Or disable the default route on that interface since it's supposed to only be used for management?
this interface is not for management, it’s the primary internet connection to these servers. The 10.19.21.180 ip on the mikrotik is just so I can access it from the 10.19.21.0/24 subnet
I don't know which Linux distro you are running, but here you can find the several ways (depending on the distribution / DHCP client used) to modify the assigned metric, as well as disabling the default route assigned by DHCP:
Since you plan to use the MikroTik router as internet gateway for the affected machines, you can disable the default route added by the DHCP server running on 10.19.21.1, or give it a higher metric by changing the settings on the client devices.
The goal here is actually not to use the MikroTik router as the primary internet gateway. I intend for nearly all of the traffic to go out over the 10.19.21.0/24 route. The only thing I plan to have using the 10.19.99.0/24 route for is a Traefik instance, and maybe some individual services that should be accessible over this route.
Either way, I have tested on a separate system where the only routes present are the ones that go over the 10.19.99.0/24 network (a laptop with only an ethernet interface enabled), and I get the exact same results there.
