Hello Community,
I'm not sure what this is supposed to be. Rant, how-to, bug report, something in between, all of it, no clue.
Over the past week or so, I've had loads of "fun" figuring out the annoying quirks of Wireless enabled RED devices in combination with an XG firewall.
A few words about the situation: we have a main office and several external employees. The external employees should surf the Web using their own local Internet connections, wherever they are, and they should only access our office LAN/VPN through the RED15w boxes. We don't want ALL their traffic going through our office XG and office Internet connection.
Most of our external employees want to use the RED boxes' WiFi, so their REDs are in regular Standard/Split mode, their WiFi Access Points are set to "bridge to AP LAN", one cable from RED WAN to their local router with DHCP. That all works fine, they can access our VPN LAN by RED WiFi and RED LAN. If the RED tunnel goes down, they just jump back to their local WiFi and they're back on the Internet locally.
One of our employees doesn't want WiFi at all, he only wants access through LAN cable using several Ethernet connected PCs and Macs. Since both of the Split modes imply "If the tunnel goes down, the remote LAN has no Internet", having his machines on RED LAN ports just won't fly. We can't (and don't want to) force him to be without Internet in his remote location, just because our office's Internet connection may be temporarily down.
A possible solution for this could be the less than just poorly documented Manual/Split mode. It's briefly mentioned somewhere, but there are zero helpful examples and no elaborate descriptions to be found anywhere, I never managed to get it working. Just by pure coincidence did I figure out this method:
Configure RED WAN to get IP from employee's local router via DHCP (e.g. 192.168.1.199/24) for Internet access and VPN Tunnel.
Configure RED LAN as Standard/Split with static IP in different subnet (e.g. 192.168.100.1/24) than employee's local router network (e.g. 192.168.1.0/24).
Configure RED LAN to access the various machines in the split (office) LAN.
Configure RED DHCP server for RED LAN interface separately (not Network > Interfaces but Network > DHCP), no pool, just one static IP assignment for the RED's WiFi AP MAC address.
Configure RED WiFi network with fixed IP in RED LAN range (e.g. 192.168.100.2/24).
Configure several client PCs Ethernet adapters with static IPs in RED LAN range (e.g. 192.168.100.20/24) using RED as gateway and DNS.
Connect RED WAN port to employee's local router LAN port.
Connect RED LAN port to employee's local router LAN port.
Connect client PC LAN port to employee's local router LAN port.
Yes, PC goes to router LAN instead of RED LAN, and both RED WAN as well as RED LAN interfaces ALSO go onto the router LAN.
Like this, in theory, when the RED boots up, it gets a WAN IP via DHCP from the employee's local router, the RED's WiFi Access Point gets its IP from the RED LAN's DHCP via static MAC/IP assignment. The RED WAN, as well as any outside devices that may find the RED LAN DHCP (because it's cabled into the router's LAN), won't get an IP from it -- since the RED LAN DHCP is set up to only provide one static IP assignment to the WiFi AP's MAC address, nothing else.
A bit counter-intuitive maybe, but two subnets on one router should not be an issue. Should work fine, right? Except... it doesn't. At least not unless you follow a specific procedure. And here's why, as I found out after days of messing about with it:
When the RED boots up, the RED LAN DHCP server (following hardware > operating system > service startup order logic) apparently only starts dealing with DHCP requests at a time when all the RED's network interfaces are already long up and running. Meaning: by the time the RED LAN DHCP server starts listening to the RED LAN for DHCP requests, the RED WiFi AP interface already went out looking for a DHCP server on the RED LAN ages ago.
Since the RED DHCP wasn't running yet, and a cable goes from the RED LAN to the employee's local router's LAN, it got an IP from the employee's local router. Giving the RED WiFi AP an IP on the router's subnet (e.g. 192.168.1.0/24) rather than the RED LAN subnet (e.g. 192.168.100.0/24).
And since the RED WiFi AP is now on the wrong subnet, it "won't play". It'll remain marked as "inactive" in the XG, it won't provide a local WiFi, and - it will stop the RED LAN's access to the local (split) Internet connection, while the office LAN is still reachable through the Tunnel.
First off - since it's the WiFi AP in the REDs that's causing all the trouble - why is there not a way to completely disable a RED's WiFi AP?
Just disabling the RED's assigned WiFi network on the XG doesn't stop the RED AP from booting up, apparently.
So having a way of disabling the entire WiFi AP functionality should be a no-brainer.
Secondly - why isn't it possible to assign a fixed IP to the RED's WiFi AP interface? It has a MAC address just like the LAN interface? So it should be able to receive a static IP address.
Having a static IP would *immediately* solve the need for a DHCP server (just for the AP) and would thereby eliminate this entire startup issue.
And finally - if the WiFi AP interface is forcedly looking for a DHCP on the LAN, without the option for a fixed IP, then why the heck doesn't the WiFi AP interface WAIT for the RED's very own DHCP to start and give it an IP address? Why does it just wander off into the big wide LAN and take an IP from any DHCP it can find? (Without waiting first)
The current state is this:
If the remote employee reboots his RED box WITH the RED LAN to Router LAN cable plugged in, the RED's WiFi AP gets an IP from the wrong DHCP, so it won't come up correctly and it brings down the remote access to the Internet. But weirdly, VPN access to our office LAN is available. This also happens when the AP's DHCP lease runs out!
If the remote employee reboots his RED box WITHOUT the RED LAN to Router LAN cable plugged int, the WiFi AP gets the correct statically assigned IP from the RED's DHCP, so it comes up correctly. Once tunnel and WiFi AP are up and running, he can reconnect the RED LAN to Router LAN cable. In this state, everything works just fine and dandy, he can access the RED LAN from his local router's LAN with all his machines, he has Internet and VPN access.
It's just a pain in the backside to maintain the RED part of it. Our external employees should plug in a box, connect to its LAN or WiFi and start working. They shouldn't be required to follow weird sequential cable plugging procedures.
All it would need for this nonsense to stop is to either let the XG configure a static IP for the WiFi AP, entirely eliminating the need for a DHCP server at all (if the remote RED LAN is manually configured anyway) -- or to have the WiFi AP wait for the RED's own DHCP to come up (if active) and ask it for an IP, before wandering off into the LAN to look for alternate DHCP servers.
BTW, once everything's up and running as intended, since no LAN machines are "behind" the RED -- once the tunnel goes down, the employee just switches his network adapter to DHCP. This gets him an IP from his local router and he can continue surfing through his local Internet connection. No cable plugging, no RED/VPN related Internet downtime.
Since I'm pretty new to the Sophos world, is there a way to get this recognized and looked into by Sophos staff?
(I tried calling their support line for a few minor reasons before, but despite paying for Enhanced Support, all they offered was "we'll create a ticket and put it in a queue, send us screenshots and an elaborate description of what's wrong". Well, was faster asking Google and trying it myself. I'm also not too comfortable with "outsiders" rummaging about in our company network.)
Or is this "not a bug, it's a feature"? Is there any particular reason why the APs should prefer outside DHCPs over the internal one, or why an "inactive" AP should bring down the remote Internet access (with Tunnel up)? Is there a reason why WiFi AP interfaces can't have fixed IPs, if they're in a manually configured environment anyway? Is there a reason why WiFi functionality of REDs can't be disabled entirely?
This thread was automatically locked due to age.