I’m using a bridged HexS just as a firewall to block a few ports. My system goes like this:
Starlink Router → HexS → Switch → Every device
It was working fine. Then the Starlink received and update and rebooted. NOW, some of my devices, instead of looking to 192.168.1.1 for their assignments got their assignments from the router and ended up with IP addresses 192.168.88.x … anyone getting assigned to 88 has no internet connection. Taking the HexS out of the configuration and rebooting the devices in question fixes everything.
My HexS is in full bridge mode with (to my knowledge!) no routing capabilities turned on. Is there an additional setting i need to tweak to stop local devices from getting assigned into the Hex’s subnet?
Remember that turning off a DHCP server does not mean that client devices instantly get an address from some other DHCP server. So if for example the Hex was issuing 192.168.88.x addresses with a 24 hour lease, it could be as much as 24 hours before those devices get an address from the Starlink router. Rebooting the client device or disconnecting and reconnecting the LAN cable USUALLY will force the client device to request a new address.
BTW, personally if it were me, I would have the Hex get its address from the Startlink router, and have all the client devices get addresses from the Hex and let the Hex function as your main router.
Zneyva, different topic. That previous one was a different issue and is solved. This one only arose after my Starlink system received an update, forcing everything to re-establish.
I think I found the problem though. When I switch from static to dynamic IP, it a new DHCP server appears, recreating the one I deleted. Instead of deleting it this time, I just disabled it and for the moment it all seems to be working as I expect.
i disagree, it’s the same issue = you fiddling with settings that you don’t understand.
I think you’re using Quickset, and then you make some manual config changes (outside of Quickset) and then you use Quickset again which overrides your manual settings.
How am I doing so far?
What do you mean switch from dynamic to static IP, WHERE WHAT,
no Znevna dont think thats the isssue, my guess is covered below:
Remember the bridge gets an IP address on the LAN of the Starlink. I am assuming as directed you assigned the IP of the bridge manually (static).
If the starlink is putting out a different LAN structure with the udpate (very possible), that means the static IP of your LAN is not longer valid and you have to change it.
If so, then starlink is to blaim for effing folks over by changing the default LAN structure.
The other issue with the reboot is that the starlink assigned the IP address that resides manually on the Hex, to another device.
THe direction was, if you had no control over IP pool of the starlink LAN, to manually assign the hex to the opposite end of the LAN used by starlink.
( Ie if starlink uses .2, .3, .4 etc, then manually assign .222 to the hex brirdge.
Perhaps the starlink kep the same LAN structure but changed assigning IPs starting at .254 etc…
Starlink doesn’t just decide to spawn a DHCP server serving IPs from 192.168.88.0/24 out of nowhere, that’s all to blame on the user, like he said above that he “magically” found the DHCP server enabled again (on the hEX).
100% PEBKAC & wrong usage of Quickset.
Yes. Everything was going fine until Starlink took an update, then everything was haywire. I changed from static to dynamic in quick setup, mostly just to see if it made a difference, attempted Hail Mary because I couldn’t find anything else that looked like a culprit, then switched it back. After getting berated here I double checked the DHCP server and it was back. So I disabled that instead of deleting, restarted everything top to bottom of the whole system, and everything seems to be working as expected now.
Znevna here is the config…
There is no 192.168.88.0 anywhere, so thats why I am thinking it was a starlink issue.
If the OP has a different config that includes 192.168.88 somewhere, then its his issue…
…
/interface bridge
add name=bridgehex
/interface ethernet
set [ find default-name=ether5 ] name=emergaccess-5
/interface list
add name=management
/interface bridge port
add bridge=bridgehex interface=ether1 { to starlink }
add bridge=bridgehex interface=ether2 hw=no {to switch - note we turn hw switching OFF for this port }
add bridge=bridgehex interface=ether3 { to whatever }
add bridge=bridgehex interface=ether4 { to whatever }
/ip neighbor discovery-settings
set discover-interface-list=management
/interface list member
add interface=bridgehex list=management
add interface=emergaccess-5 list=management
/ip address
add address=192.168.2.X comment="address of hex on starlink lan subnet"
add address=192.168.5.1/24 interface=emergaccess network=192.168.5.0 comment="ether5 access off bridge"
/interface bridge filter
add chain=forward mac-protocol=ip ip-protocol=udp in-interface=ether1 dst-port=8100-8110 action=drop
add chain=forward mac-protocol=ip ip-protocol=tcp in-interface=ether1 dst-port=8100-8110 action=drop
add chain=forward mac-protocol=ip ip-protocol=udp out-interface=ether1 src-port=8100-8110 action=drop
add chain=forward mac-protocol=ip ip-protocol=tcp out-interface=ether1 src-port=8100-8110 action=drop
/ip dns
set allow-remote-requests=yes servers=192.168.2.1 comment="dns through trusted subnet gateway"
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.2.1 comment="ensures route avail through trusted subnet gateway"
/ip service
set winbox address=192.168.2.X,192.168.2.Y,192.168.5.0/24 etc. *****
/tool mac-server mac-winbox
set allowed-interface-list=management
EDIT, THE FOOL TOUCHED QUICKSET, I bow to the master Znevna!!!
So… yeah. Don’t trust Quickset to do anything good after you mess with the settings outside of Quickset.
Either you use ONLY QUICKSET, or you use it once and then you never touch it again.
Your MikroTik initiation guide should’ve started with this.