Hi

Any pointers on configurint wireless on wAP R from nothing? It will be an AIO small network gateway for an apartment utilities room. What specific docs to look through or what other forum posts there might be?

I just did a clean netinstall and added the LTE and Wireless package, but it seems pretty barebones at the moment. I am not looking for vlan-s or anything. I am planning for a wireguard connection aswell for remote management.

Good question. IMO, the defaults in recent RouterOS are pretty good. And, it acts like any common home router by default. So you don't necessarily need to do very much.

Here are some general pointers & most are just considerations, rather than "you MUST do this":

0. The most important thing is NOT to use "admin" and/or even the default password. So create your own account, using a different username and complex password, and put the new user in the "full" group to use as the "admin" account. Then remove (or disable) the admin account.

1. Upgrade firmware RouterBOOT and set "auto-update=yes" for automatic updates - https://help.mikrotik.com/docs/spaces/R ... outerBOARD
- To check/update the firmware, it's in System > RouterBoard in webfig/winbox
- If you enable autoupdate it applies ONLY the firmware & mean if you upgrade RouterOS and reboot, if you reboot a 2nd time, the latest firmware will be upgraded. RouterOS cannot do BOTH OS and firmware in one step... I just set the auto-update once, and "reboot twice" when upgrading RouterOS packages as routine in future.
- Especially for LTE, the firmware version matching the RouterOS version may avoid some issues.

2. Upgrade LTE modem - see https://help.mikrotik.com/docs/spaces/R ... areupgrade

3. Think about if "device-mode" changes are needed - https://help.mikrotik.com/docs/spaces/R ... evice-mode
- RouterOS has the ability to disable certain features, this reduces the attack surface.
- Specific to wAP R, I cannot imagine any changes be need - but newer devices might want/need to enable container
- The default are pretty reasonable in 7.16 (but may change in future) ... but if you're really not using IPSec or PPTP, etc, you can theoretically disable them.

4. Remove unused /ip/services - https://help.mikrotik.com/docs/spaces/R ... P+Services
- disable any of the ftp, api, etc protocols (unless you're using them)
- the web/browser admin interface, webfig, need http and/or https — but if only using winbox to manage, then even http is not needed

5. Disable /interface/detect-internet - https://help.mikrotik.com/docs/spaces/R ... t+Internet
- this may be enabled by default, and does NOT do exactly what the name implies & mostly useless
- but... detect-internet being enabled can have nasty and potentially surprising side effects
- to disable set the "detect-interface-list" to "none" (its dialog box is under Interfaces in winbox/webfig from the button)

6. Do "something" with /ipv6/settings
- See docs https://help.mikrotik.com/docs/spaces/R ... v6Settings
- if your LTE carrier/WAN does not have an IPv6 address, or not using IPv6... I'd recommend disabling using "disable-ipv6=yes"
- and if disabled in /ipv6/settings, you'd likely want to disable it on the LTE APN settings set mode to ipv4 if you disable IPv6, see https://help.mikrotik.com/docs/spaces/R ... PNprofiles
- If you want to use IPv6, the defaults are okay, but IPv6 typically requires tweaking based on the ISP or cell carrier. The specifics of LTE with IPv6 depend a lot on the carrier, so it's not generally a simple "cut-and-paste" of some config since it depends on a carrier's specific IPv6 topology/schemes.

7. WireGuard - https://help.mikrotik.com/docs/spaces/R ... /WireGuard - ... or QuickSet + L2TP
- One thing to note is QuickSet does support adding "VPN" via a checkbox on the QuickSet window. This enable enable get a IPSec+L2TP VPN setup pretty automatically (using vpn as user, and "password" is the PSK and password AFAIK) so that's one option, although you might go to /ip/ipsec to secure the account further
- WireGuard also work, and docs describe the steps, and in most cases requires limited firewall modification.
- Both WireGuard and L2TP require one end to have a public IP, since this not common with LTE. The other end of the connection would need have a public IP (and WG or IPSec being enabled as a "responder", see docs)

8. /tool/watchdog and /tool/netwatch
- The hardware watchdog (i.e. kernel panics or get frozen) is enabled by default, which reboots the router. I'd recommend making sure that's enabled. See https://help.mikrotik.com/docs/spaces/R ... 4/Watchdog
- Likely you'd want also enable the "ping watchdog" and use the same DNS server as RouterOS is using in /ip/dns. What this does is if a ping fails for the period configured (see doc links above), it will automatically reboot the router. Since LTE interface might have some future problem/issue, and rebooting the entire router might potentially get LTE running again. So if remote... you'd want it to reboot if WAN link was down, to perhaps/hopefully, get back in....
- /tool/netwatch has a lot of similar options, but it's not checkbox... rather a few more sophisticated scheme, than plain "ping watchdog & takes some scripting take any action. See https://help.mikrotik.com/docs/spaces/R ... 8/Netwatch - - If using LTE, adding a netwatch that runs every 1 second, sometimes, can help a little with LTE speeds/latency/etc and maintaining CA - cell towers prioritize active users. So if there are periods of NO traffic on LTE, keeping a "heartbeat" using netwatch going might prevent the tower from re-allocating things on the LTE session. LTE bandwidth is somewhat a "use it or lose it" situation.

9. Limiting LAN(s) /ip/firewall/filter or /interface/bridge/filter or /routing/rules
- By default, all devices can talk to all other devices on LAN, including the routers... If this is what you want, no change to firewall should be needed.
- And all inbound ports (other than ping and IPSec) are block to LAN, a /ip/firewall/nat with a dst-nat (or QuickSet) is how you do "port forwarding" - but LAN is protected by default config without changes.
- If you want "block" some devices from communicating with other devices, the specifics matter... VLANs is a typical way to separate/control traffic since crossing VLANs causes the traffic to flow through the router where an IP firewall filter can be applied.
- But even without a VLAN, you can certainly restrict some LAN devices from reaching the internet access via a /routing/rule using "src-address=192.168.88.xx action=drop" - https://help.mikrotik.com/docs/spaces/R ... cy+Routing
- Also, without a VLAN, you can restrict traffic between two [LAN] ports on the wAP R router using https://help.mikrotik.com/docs/spaces/R ... geFirewall

10. If public IP, think about enabling DDNS
- since you're using LTE, may not be possible... and really only needed if using webfig or VPN/etc services that use certificates...
- but it's likely a good idea to get a certificate for https in /ip/services since that will encrypt webfig's traffic, so you can disable http in /ip/services
- Mikrotik supports Let's Encrypt and has a built-in DDNS services - BUT it requires a public IP on WAN, which is not likely with LTE.

11. Specific to DHCP client and LTE APN, you may want to disable "Use Peer DNS" and manually set the DNS servers in /ip/dns - https://help.mikrotik.com/docs/spaces/R ... 748767/DNS
- by default the LTE or other WAN's DNS servers are used, but in nearly all cases using one of the public DNS servers be better to avoid have no DNS set in future - i.e. if LTE gets disabled, the DNS servers go away go. Now if LTE is only internet, it kinda does not matter - but if you add a 2nd WAN etc, then using a fixed set of DNS servers avoid a lot problems with multiwan routing.

Is the upstream router its connected to a Mikrotik Router??

Please allow me to doubt the advice in #1, the good Mikrotik guys are not particularly cautious when tagging a release as "stable" and - if not common - it is far from unusual that in releases marked as stable (and thus subject of automatic updates) new or regression bugs appear.
Of course it is unlikely that such possible issues affect basic configurations and/or basic working of the devices, but it has happened (and it is actually happening related to instability in some Ax wireless connections, there are a couple of threads where people are forced to stay a couple releases back to keep things working reliably).

There is a difference on setting auto-upgrade to yes for routerboard (=FW) and doing auto-upgrade for ROS.

Last one: big no-no ! Your explanation 100% applies there.

First one: I haven't yet seen a case where it caused troubles to keep Routerboard and ROS at the same level. Have you ?
The only thing setting auto-upgrade to yes on Routerboard does is WHEN you upgrade ROS (which at that moment is your choice, or it may be the result of some automated process which still should be under your control), the next reboot FW will upgrade too.
And that is what Amm0 refers to.

PS Amm0: nice post !!

One addition: list by @amm0 in bullet #7 mentions QuickSet ... IMO it's worth mentioning that if user did anything according to bullets 3-11 outside of QuickSet (which is very likely), then use of QuickSet is a very avanturistic act since it can revert some of changes (but not all) and hence end result is anything but well defined.

I'm waiting for @jaclaz to paste his basic rules

Yes, limited to the routeboard firmware, automatic update is probably OK, still the usual advice is to have Routerboard firmware release "aligned" to the Ros (let's call it "software") version, so if setting the one, there is the risk to have it automatically be one or more versions "forward" relative to the other. Since if you have firmware update automatic and software update manual you anyway need to intervene manually (and have to reboot twice) I don't see it as a complication or an inconvenience to manually update both, when needed/wanted.

I'm waiting for @jaclaz to paste his basic rules

...and I have a new #3 (which is actually Amm0's #0), shifting the old #3 and #4 down one notch:
Rules of the Mikrotik Club:
1) You do not use VLAN1
2) You DO NOT use VLAN1
3) You remove default user admin and set a strong password before connecting to the internet.
4) You do not use Quickset.
5) You do not use detect internet.
6)...

Now #6 might be added as either:
6) You set automatic updates for routerboard firmware but not for ROS.
or
6) You do not set automatic updates.

Opinions on these two alternatives are welcome .

Now #6 might be added as either:
6) You set automatic updates for routerboard firmware but not for ROS.
or
6) You do not set automatic updates.

Since your rules are intended "for dummies" (seasoned MT admins already live by these rules, right?), I'd go for the former ... although personally I use the later (but I'm concious about routerboot upgrades and act if I deem necessary).

... although personally I use the later ...

Couldn't that be called "preaching virtue but practicing vice"?


Seriously, I have found at least one case where firmware upgrading caused issues (in an old 6.4x.yz version):
viewtopic.php?t=180096

It seems like there are contrasting opinions by Normis and rextended here:
viewtopic.php?t=196291

At the moment it seems like points for the first are ::
Amm0 1
holvoeth 1
rextended 1
mkx 0.5
total 3.5

and for the second:
Normis 1
jaclaz 1
total 2

(and the former votes have surely a larger weight) .

Note to self (for the future), I just noticed that there is a slight distinction between the verbs used
firmware -> verb used is "upgrade"
ROS/software -> verb used is "update"

... although personally I use the later ...

Couldn't that be called "preaching virtue but practicing vice"?

Nope, not in case of routerboot upgrades ... I've never imposed (ever so mildly) suggestion in any direction in any of my posts (I'll buy you a beer or any other beverage of your choice if you can find my post telling to do either of options).

As to contrasting options: I seem to remember @Normis saying that there's no need to upgrade anything if device works fine (as response to complaints that upgrade broke a working setup) and on the other hand @Normis saying that device should be upgraded regularly to keep it as safe as possible (it still remains open as to what to do with botched config, default is not entirely immune to this, ROS uprade rarely does anything with config). So I guess we won't ever reach an unanimous option here.

There have been recent ROS versions where one of the prerequisites was the routerboard version needed to be upgraded as well ( or at least be a certain version). No ?

Staying aligned makes sure there will be no conflict for that part.

Mkx:
I do recall some post from you stating esp. on ROS6 routerboard was not needed to be adjusted per se but that since ROS7 you keep it more or less in sync ?

Some "essential" new ROS features require routerboot upgrade. Such as device-mode. (IIRC there were no such changes in ROS v6, routerboot changes were only necessary when hardware initialization had some problems).
Also to boot ROS v7, one had to run some minimum version of routerboot (something like 6.46 or there abouts) on their devices, older routerboot could not boot linux kernel from v7.
Another case where routerboot upgrade was recently required were some fixes in PoE-out behaviour IIRC. So yes, generally it's good to recomend routerboot upgrades every time (hence setting auto-upgrade to yes).

OTOH in most (if not all) cases, when touterboot actually got changed, this was mentioned in change lig. So if one follows that information channel, it's possible to figure out when routerboot upgrade is necessary and when not. But: how many users (apart from most passionate ROS affectionadoes) do follow change log?

My commentary originally was "not much", then turned in a rather long list... To answer some "suggestions on the suggestions"...

On "firmware" and/or RouterBOOT and/or BIOS – i.e. auto-update in /system/routerboard...
- OP mentioned LTE... and my experience is that latest firmware has never caused a problem, while mismatched version has caused LTE interface not come up.
- @rextended's commentary in other thread is right: it's unclear if there are changes in firmware that might be needed for some feature
- automatically upgrading RouterOS in /system/package was NOT suggested, and not even some option to just enable...

I forgot there is also the LTE modem firmware...
- I forgot to mention if it's a Mikrotik modem in there, the 3rd software thing to update be the LTE modem's firmware in /interface/lte....
- Some CLI commands to do various updates are in this post (and a bit US centric) are here: viewtopic.php?t=199087&hilit=band+66&si ... d#p1025119

QuickSet and IPSec VPN...
- OP has the default configuration, so running QuickSet multiple times is fine. In reality, QuickSet really just looks for comment/name "defconf" and changes those things. It does not change or reset other things, outside what appears on the QuickSet screen. Now changing the QuickSet mode in top-left corner, may change the bridge... and changing that is more invasive - but only because it changing bridge ports.
- On some older devices, IPSec may be offloaded is why I just mention it as a possibility. I don't think the wAP R has offloading, so WG and IPSec likely have similar CPU needs (and both likely be relatively slow on wAP R).
- But was not trying to get into a debate about which VPN is best - more mentioning there is a checkbox in QuickSet to add a VPN in one step, and no client app needed with L2TP.


Wireless settings for older 2Ghz...
- Did not actually cover the "wireless" part in the title...
- The most important thing there is set it up as "normal" AP is make sure distance=indoor (critical) is set, and a few other related settings: - Recommend to just pick a channel to use, and NOT use "auto" for frequency. Generally speaking for 2Ghz, picking either top choice or bottom choice for frequency in dropdown be better than using auto... Look at the frequencies scanner be better to guide selection.
- Additionally, the band should be set, unless you have 802.11b (very old) or 802.11g (older) devices, you want to say use only "only"
- /interface wireless set [ find default-name=wlan1 ] band=2ghz-onlyn
- Same for country, set as needed:
- /interface wireless set [ find default-name=wlan1 ] country="united states3"
- You want to also set installation=indoors (or wAP R is installed outside, may want set outdoor) - FWIW this likely effects power used, based on country-specific rules...
/interface wireless set [ find default-name=wlan1 ] installation=indoor

I agree that the the firmware should be aligned to software , what I am not convinced of is to set it as automatic, since the software update is anyway advised as been done manually, I don't see how having the firmware set to automatic is "better", you have anyway to remember to reboot twice, so you can as well remember to upgrade the firmware.

Also, I don't really understand the logic of the "update ROS first, then upgrade firmware at next reboot":
viewtopic.php?t=199442

It seems that *any* firmware (unless - maybe - if extremely old) must be able to boot *any* later RoS version, and the new firmware only "unlocks" (in some cases) some new features of the new RoS version.

Logically - if we agree that a "latest" firmware should be able to boot *any* previous Ros version - it would make more sense to first upgrade the firmware and only later update the Ros.

Also, what is the advised approach to "downgrading"?
I have seen many reports of people that have issues with the new/latest "stable" and go back to a previous Ros version temporarily, waiting for a bugfix in a "next" Ros release.

Does the "automatic" upgrade of firmware cause a "misalignment" of versions?


All in all, rule #6 could be:
6) You keep routerboard firmware upgraded to the same release as Ros software update

Also, I don't really understand the logic of the "update ROS first, then upgrade firmware at next reboot":
viewtopic.php?t=199442

As I wrote in the last post of linked topic, FWF files (containing routerboot images) are inside ROS disk image. Generally installer installs new ROS image while running previous version of ROS and then reboots device (to get new ROS booted). So those new FWF files are not available to ROS installer, so they can't be installed together with new ROS to be already active when reboot happens.

Well, the last sentence is the big disagreement between MT and us (ROS zealots). Us, we believe it should be possible to arrange things in a way which would make FWF files available for ROS updater (and updater could install them before first reboot). MT (@Normis in particular, but I guess he can talk authoritatively for MT) are saying that this is not possible. And that enabling routerboot auto upgrade is the best thing to do (another reboot is still needed to activate new routerboot firmware).

As to device-mode locks: as far as I understand, recent routerboot is necessary for those bits to be stored properly (and then retrieved). Older routerboots without support won't be able to provide device-mode settings to ROS. I've no idea what ROS does if routerboot doesn't provide that array of bits, probably it sticks to some defaults ... and defaults are probably the same as the ones imposed on upgrade from older ROS (and we don't like those defaults), hence running ROS 7.17 on top of some 6.49 routerboot wouldn't help.

Does the "automatic" upgrade of firmware cause a "misalignment" of versions?

No, it doesn't. "upgrade-firmware" under /system/routerboot will show any version, available in ROS (either FWFs coming with system package or custom FWF file, present in root of storage) if version number differs from the one installed ("current-firmware") ... and that's true both when available version number is higher or lower than current. And command upgrade will simply install routerboot firmware, listed as "upgrade-firmware". So when one downgrades ROS, "upgrade-firmware" will list routerboot firmware which comes with now downgraded ROS ... and if it's somehow upgrade-d, it'll get aligned with ROS version after next reboot.

I don't see how having the firmware set to automatic is "better", you have anyway to remember to reboot twice, so you can as well remember to upgrade the firmware.

It's eventually get upgraded if one forgot...since at some point you'll reboot. My list was more "unless you know better", you're likely better off doing this....

At some point in future, it's possible some security fix may require a RouterBOOT upgrade. But given how hard it is weed out the admin/nopassword in Meris attack... I can only imagine how difficult it be for critical[/theoretical] RouterBOOT fix to get deployed in practice. So more devices with auto-update=yes in /system/routerboard seems better approach, given how RouterOS works today.

All in all, rule #6 could be:
6) You keep routerboard firmware upgraded to the same release as Ros software update

Given the positive feedback, I'll likely re-write the list in a new post.


Also OP @tafkamax - we've hijacked your thread a bit. But you do have a lot of expertise here, so let us know if you do have some more questions.

Any pointers on configurint wireless on wAP R from nothing?