How to Give a WISP Client a Public IP on MikroTik | Part 2 VLAN 30 Test

Hey everyone — Moe here again from WvW Networking Solutions. This is Part 2 of the MikroTik WISP public IP setup, and in this video I continue right where the last one left off. In this part, I fix the NAT mistake that caused the client-side issue, verify that VLAN 30 is passing correctly through the bridge and AP, and then move a real client from the private WAN side over to the public-IP VLAN to prove the setup works. One of the first things I go over is the mistake with source NAT. In the previous setup, the NAT range did not match the subnet correctly, and because of that, the radio was not being natted properly and lost access the way it should have been working. So in this video I explain what happened and why it broke. After that, I briefly touch on firewall rules and the difference between protecting the router itself versus trying to deeply inspect and protect all client traffic. For this kind of setup, the goal here is to keep the router protected without overloading it with unnecessary filtering tasks. Then I go back through the public-IP VLAN setup: VLAN 30 created for public-IP clients IP address assigned to VLAN 30 DHCP server added for VLAN 30 VLAN 30 verified on the bridge VLAN 30 verified on Ether8 VLAN 30 confirmed on the AP side From there, I log into the AP and confirm the network configuration is correct. I also show that both VLAN 20 and VLAN 30 are present where they need to be before touching the client side. For testing purposes, I temporarily nat the test public range, since this lab setup is not using a real routed public subnet. That way I can still prove the concept and show the public-IP VLAN behavior in action. The main part of this video is moving the client from the regular private WAN VLAN over to VLAN 30 so the client radio now exits through the public-IP side while still keeping management traffic private. That is a key point in this setup: the client can get public-IP internet access without wasting an extra public IP on the management side. I also explain why I prefer keeping the client radio in router mode instead of bridge mode in many cases. If a customer accidentally plugs their equipment in the wrong port while using bridge mode with DHCP, they can create a mess on your network. In the real world, that can cause conflicts, bad leases, and calls in the middle of the night. So I break down why bridge mode needs more caution and why static addressing matters if you decide to go that route. Once the client is moved to VLAN 30, I show the lease changing and the client pulling a 100.100.100.x address. Then I verify the path from the client side and confirm that the setup is working as intended. Near the end, I also talk about why VLAN separation matters beyond public IPs. It helps keep management clean, prevents wasting public addresses, and gives you better control when you want to isolate or deprioritize certain traffic classes later — such as gaming consoles or heavy update traffic during peak hours. I also touch on the next steps in the series, including viewing a locally hosted UISP controller from a phone, and I give some practical advice on MikroTik hardware — including why the L009 is better treated as a switch in some cases and why the RB5009 is the better option if you really want to push more throughput. If you’re building a WISP or small ISP and want practical real-world MikroTik setups explained in plain language, this series is for you. Chapters: 0:00 Intro / Back for Part 2 0:38 The NAT mistake from Part 1 1:37 Basic firewall rules discussion 2:36 Why the source NAT broke the client connection 3:30 Recap: VLAN 30 and public-IP setup 4:26 DNS note: Google DNS vs router DNS later 5:11 Verify VLAN 30 is tagged to CoreBridge and Ether8 6:05 Confirm VLAN 20 and VLAN 30 on the AP 7:15 Temporary NAT for testing the “public” IP 8:12 Move a client from private WAN to VLAN 30 9:44 Check leases before the change 10:43 Why management stays private 11:27 Router mode vs bridge mode warning 15:36 Change the client WAN to WLAN30 17:01 Client pulls 100.100.100.30 public IP 18:02 Test from the client side 19:05 Confirm gateway path and internet access 20:06 Why VLAN separation saves public IPs 21:02 Using VLANs for traffic policies and gaming clients 22:18 Next video: UISP local controller on phone 23:03 MikroTik L009 vs RB5009 advice 24:02 Future topic: RSTP failover between towers 24:34 Wrap-up Drop a comment if you want Part 3 next. #MikroTik #WISP #PublicIP #VLAN #RouterOS #WirelessISP #Networking #DHCP #UISP #Winbox