All devices on Local LAN are going through the GL-MT2500 even though it is set to be a Drop-in Gateway. (per instructions)
The goal is the have the GL-MT2500 only service the single device hard connected to it, not service all network devices.
As per the instructions, the GL-MT2500 is wired from the WAN port to a LAN port on the Main Router.
Main Router has a “Static Lease” IP address established for the GL-MT2500. (everything works fine)
LAN: Router IP Address: 192.168.29.1 (GL-MT2500 obfuscated address)
LAN: Number of users: 100
LAN Advanced: (I did not change this configuration page)
– Router IP Address: 192.168.29.1 (GL-MT2500 obfuscated address)
– Netmask: 255.255.255.0
– Start IP Address: 192.168.29.100
– Endi IP Address: 192.168.29.249
– DHCP Gateway: (blank)
-A single device is hardwired to the GL-MT2500. It is getting an IP address from GL-2500 nework. 192.168.29.51 (obfuscated)
Yet, all of the main LAN devices are being routed through the GL-MT2500 connection. They are all getting their IP addresses from the main router’s DHCP.
All devices appear to find the GL-MT2500 as the “Default Gateway”, even though it was configured not to do that? Once it is disconnected, devices go back to seeing the Main Router as the default gateway as it should be.
The upstream router is expected to be the sole DHCP so there’s nothing unusual there. The ‘Drop-In Gateway’ feature works by ARP spoofing; that is, it sends peridoic packets out to all connected devices that trick said MACs to route thru the Burme 2 before heading upstream. It’s how your devices then use the VPN Client mode under this configuration.
The green lines indicate that when the Drop-in Gateway mode is enabled, all or part of the devices’ data will be processed by the GL.iNet device before being sent out through the main router.
[ Emphasis mine ]
I don’t think there’s the ability to ‘Split ARP Spoof’ so Drop-In Gateway only impacts certain MACS in the GL GUI. You might have to head into LuCI or the CLI to set up some ‘static ARP entries.’ I’ve never used such a conf, myself.
Related: There’s a post floating around from within the last 2 weeks or so that GL is in the process of re-working this feature as they state they’ve found it to not be wholly reliable. They’re working on a new technique. Apologies I can’t think of the thread ATM. I believe it was a response fr @yuxin.zou .
That makes complete sense. Thank you so much for the response.
The idea is to create a subnet of devices that keep their traffic seperate, sort of like dual NIC’s in a PC would do, but without having the overheard of a PC. (My idea is to have home security cameras with their own subnet, going through their own VPN… etc.) I’m only part way through trying to figure this out and got stopped when I found ALL traffic going through the GL-MT2500.
Do you know if their is a different product I should have chosen?
The amount of knowledge you possess to quickly identify the root cause of this is impressive, to say the least.
Today I learned about ARP spoofing, how and why it works as well as legitimate reasons for its use.
“… ARP entries … will be overwritten when a new ARP reply packet is received. There is no method in the ARP protocol by which a host can authenticate the peer from which the packet originated.”
If I read of a “solution” or work around, it is to go to each individual client and manually set their IP address and Gateway (static). (edit) This then stops them from listening to and changing the ARP entries.
This could work as a short term solution on a small network (until I find a correct product or they resolve this issue for the GL-MT2500)
It can be done of course but you’re going end up relying on LuCI & CLI more & more for subnet segregation setup. Multi-VPN is a wholly seperate issue. The current GL GUI is going to be a limiting factor but not the only one:
Cutting right to the chase regarding that you’re looking to add various VLANs for different devices (eg: cameras) then I don’t think the Burme 2 is the GL device for you long term. Technically you could add a USB3 NIC (network interface card) driven by kmod-asix but that’s still going to leave you restricted to two NICs for subnetting. Prehaps a little 5 or 8 port switch can expand ea. subnet accordingly. You’d end up with a nice little ‘rats nest’ of ethernet cables & power adapters though overall it’s not very expensive compared to buying a whole new router. The overall setup would be slightly more ‘brittle’ if/when GL firmware updates come through thus impacting uptime & potentially requiring more manual intervention.
If your budget can bear it I’d look to replace your Burme 2. Given you’re implying this is a stationary network (ie: you’re not travelling) then I would hold tight until the newly announced Flint 2 (MT6000) hits retail channels… 900 Mbps over WireGuard!
Drop In Gateway in version 4.1 firmware uses ARP spoofing. But in version 4.2, it no longer uses it.
Simply put, using ARP spoofing makes configuration easy. It doesn’t require other parameters to be configured on the Drop In Gateway page, but it can make the network unstable.
4.2 and above use DHCP and the MT2500 will act as a DHCP server to assign IPs to clients on the subnet.
The cause of this problem is DHCP server conflict. This is a design flaw and we are trying to fix it.
If you do not disable the DHCP server for the main router, there will be two DHCP servers in the LAN. The client receives its IP from whichever DHCP server is randomized. Here. for some reason. it is clear that the MT2500’s DHCP server is stronger.
If you want to solve it. The best solution is to disable the DHCP server in LuCI.
GL-MTxxxx attached to main router via wan port
-drop in gateway enabled
-LuCI → DHCP server disabled on the WAN interface
DHCP still on for LAN interface and WIFI interface
Devices conntected to LAN port or WIFI interface obtain IP from GL-MTxxxx
Devices connected to main router obtain IP from main router, but I can configure the gateway to the GL-MTxxxx IP and everything gets routed via the GL device.
(in my case it is easy to check as the GL establishes a wireguard connection to Germany, so a simple what is my IP check will tell whether the traffic is routed correctly) @bbwolfe - I hope this also works for you…
Glad to see Brume 2 getting improvements for Drop-In mode.
My use case is: Use Brume 2 as Adguard/DNS for local network, VPN client for a few devices but keep existing router
Keep my existing router as main router/gateway. Also have main router to continue to hand out DHCP and reserved addresses. e.g. 192.168.1.1 - 254 clients
Use Brume 2 to supply Adguard/DNS to all local clients AND a few local clients VPN clients through Brume 2. The VPN clients would be configured to have local fixed IPs and to explicitly use Brume as Gateway and DNS server.
e.g. Brume 2 fixed ip 192.168.1.2 but use existing router as gateway for Brume 2. Brume 2 running Adguard. And configure Brume VPN client to connect to commercial VPN server subscription
Point main router (192.168.1.1) to 192.168.1.2 (Brume) for DNS
VPN client machine(s) - e.g fixed IP 192.168.1.100, gateway 192.168.1.2 (Brume) and DNS 192.168.1.2 (Brume) - thus connected to commercial VPN service
