Hi, my first time posting and would like new setup advice on moving over to Mikrotik?
-Can my new hEXs handle my back office securely from my Hotspot?
-My Hotspot is small under 30 clients.

I'm new to Mikrotik, but think I've found it's the right way to go finally.

My existing router setup:
Main router for back office Linksys WRT54GL with DD-WRT.
Second router is the same WRT54GL coming off the main router lan for guest (hotspot) network.
GOAL: replace both routers with my new hEXs

Also existing:
-EnGenius wireless bridge wired to lan on second router with Engenius AP at remote end.
-(2) EnGenius wireless AP wired to second router lan.

I've setup the Microtik Hotspot and have been testing with EnGenius AP. Usermanager works and I think I have the Hotspot configured correctly. I config the landing page nicely.
Cable ISP WAN on ether1 and all lans bridged to ether1.

I would appreciate any help/directions!

Thank You!

Is there anyone for hire? That can write my system script or help give me direction.

Thanks

https://mikrotik.com/consultants

I tried (3) off your link and they all want $1500 to $2000.

I just need a little guidance! Just a few questions answered. I feeling it's very hard to get help on this forum.

It depends, hotspot and userman are not the most commonly used features, so there are less people who can help you with your requirements regarding these. Also questions like "my config for feature X doesn't work, it fails in this specific way, here is exported configuration, logs and everything, what can I do?" are easier to answer. Your post sounds like you're on right way, everything seems to work, ... so it's difficult to give you tips when nobody really knows much about what exactly you have.

I'm just explaining, hotspot and userman are not my thing. But try to be more specific and hopefully someone will be able to help you.

Sure and thanks - myconfig is attached, I think attachment is the preferred way. Please let me know.

I want to:
-create backoffice secure from the Hotspot

I have an existing wireless network.
I know I can disable security on all my AP's and plug them into the Mikrotik router and the Hotspot will work/handle clients. Is this correct?

Need advice?:
- I have some IP cameras on the AP's, how should I config them? I think Vlans?

Thanks

Where is backoffice? Connected to main router and this config is from second one, right?

In any case, you can prevent communication between different networks using firewall filter. Use statefull firewall, something like this: Devices in LAN1 can connect everywhere (LAN2, WAN, whatever else there is). Devices in LAN2 only to WAN (but not to LAN1). You get the idea.

Not exactly something where I shine, but if by security on AP's you mean WPA2, I think it's good idea to leave it there and not have the network completely open.

VLAN for cameras sounds like a good plan. Or one VLAN for them and other for users, whatever your APs supports. If they send tagged packets to RB, you can make interface for each VLAN and work with them like with any other interface.

Some random hints:

- Export has useful parameter "/export hide-sensitive"
- When interface is in bridge (your ether5), IP address should go on bridge, not on the bridged interface.
- It's good idea to secure access to router, it's done using firewall too, only in chain=input. Same idea as with forward, allow what you need, block the rest. You don't want to give hotspot users opportunity to guess router's password.

Where is backoffice? Connected to main router and this config is from second one, right?

In any case, you can prevent communication between different networks using firewall filter. Use statefull firewall, something like this:

Code: Select all

/ip firewall filter
add action=accept chain=forward connection-state=established,related,untracked comment="allow existing connections and some other ok stuff"
add action=drop chain=forward connection-state=invalid comment="block invalid packets"
add action=accept chain=forward in-interface=<LAN1> comment="allow from LAN1 to any destination"
add action=accept chain=forward in-interface=<LAN2> out-interface=<WAN> comment="allow from LAN2 to WAN"
...
add action=accept chain=forward connection-nat-state=dstnat comment="allow forwarded ports"
add action=drop comment="block everything else"

Devices in LAN1 can connect everywhere (LAN2, WAN, whatever else there is). Devices in LAN2 only to WAN (but not to LAN1). You get the idea.

Not exactly something where I shine, but if by security on AP's you mean WPA2, I think it's good idea to leave it there and not have the network completely open.

VLAN for cameras sounds like a good plan. Or one VLAN for them and other for users, whatever your APs supports. If they send tagged packets to RB, you can make interface for each VLAN and work with them like with any other interface.

Some random hints:

- Export has useful parameter "/export hide-sensitive"
- When interface is in bridge (your ether5), IP address should go on bridge, not on the bridged interface.
- It's good idea to secure access to router, it's done using firewall too, only in chain=input. Same idea as with forward, allow what you need, block the rest. You don't want to give hotspot users opportunity to guess router's password.

Sob - thanks for helping, any directions are useful!

This Mikrotik router I sent the config file isn't in production yet, just testing. So no password. I have to make sure of the protection between Hotspot and backoffice first before production. Trying to get it configured.

I'm wanting to replace the 2 current routers (Linksys wrt54gl) I have with the new Mikrotik hEXs

Questions: If I don't leave AP's wide open (no security WPA2) then they won't work with the Hotspot. Doesn't the Hotspot stop anyone from getting internet service? Shouldn't Hotspot do the authentication?

-I haven't used Vlan's, but know what they are so I will need help enabling the interface in the Mikrotik router - yes my AP's do tag packets (like 1,2,3,4).
-I've been reading pcunite's thread on Vlan's and it's great, but a lot of info to put together.

Thanks

- AP security - I see it as different levels. WPA2 should make sure that anyone can't see what's flying through the air (although I'm not sure how much it's true for shared PSK that anyone knows). And if you don't advertise the password to whole world, not every random person who sees the AP will be able to connect (but maybe you do want that). And then hotspot is the next level for users who were allowed to connect to wifi.

- VLANs - If all devices would be connected only to one port on router, it's enough to add VLAN interfaces on that port. If multiple ports are used, it needs a little more config, but not too much. I like examples in manual, they are short and easy to understand.

My Hotspot - Clients will purchase per-generated voucher for user id and password. So I think the AP's left open is right?

-VLANs - I want to use (1) router interface port for the wireless bridge, which has an AP at the remote end.
AND
(1) router interface port for (1) AP
AND
(1) router interface port for (1) AP

I'm hung-up on the VLANS setup, but looking for the combination. The manual link is good, but not sticking yet. I will continue reading over....

Thanks Sob for your time, your helping!

Pictures is worth a 1000 words - this is what I'm trying to accomplish and it's a challenge.

Any help is appreciated!

I need some direction.

Looking at my network diagram. Let me know if I'm on the right track?

AP-1:
-VLAN for Backoffice (say VLAN10) for the IP camera.
-Not sure what I need for the Hotspot? I think leave open for usermanager on SSID (myhotspot).

AP-2:
-Just for Hotspot. So leave open for usermanager on SSID (myhotspot).

AP-3:
-VLAN for Backoffice computer (say VLAN10).
-SSID (myhotspot) for HotSpot (open for usermanager)

So create a VLAN for just BackOffice and not the HotSpot?

I'm I on the right track? Please advise?

There's nothing clearly wrong with the image, and I'm sure it can be configured like that. But there's usually more than one possible solution, and to decide which one is the best is difficult without knowing all details about existing network. And it's not easy to explain those accurately to someone else, not leave something out, etc.

Whether you put one network in tagged VLAN, or the other, or both, doesn't make much difference. It also depends on your other equipment, what's possible. I'd suggest to continue reading about VLANs, do some experiments (you have two free routers for that) and once you get hang of it, it will become clear what's best for you.

Sob the diagram is my existing network, running on (2) Linksys routers.

I just need to know how would you set this up on the Mikrotik router, so I can only use the Mikrotik router and ditch the Linksys?

Thanks

I don't see where exactly you have two routers, it looks like one should be enough (but there's no major difference between one and two, you'd just spread the config between them). So one independent port would be WAN, and the remaining four would go in bridge. Office can be directly on bridge untagged and hotspot in tagged VLAN (you need to configure your APs to tag hotspot traffic). So bridge will be LAN interface for office and VLAN interface will be where you add hotspot.

The only thought to consider:
hEX S have a very weak switch chip implementation - it can't do vlan's in hardware, only in software.
It is not a real problem for small loads, but depending of the intra-vlan/inter-vlan ratio it can be a good idea to put a more decent switch between hEX and the rest of the network, so only inter-vlan routing is done on the hEX, and all intra-vlan switching is done on a switch.
If the existing Netgear switch is a managed type and if it can be done "geographically", you can rearrange your layout to use it, instead of the extra one.

I don't see where exactly you have two routers, it looks like one should be enough (but there's no major difference between one and two, you'd just spread the config between them). So one independent port would be WAN, and the remaining four would go in bridge. Office can be directly on bridge untagged and hotspot in tagged VLAN (you need to configure your APs to tag hotspot traffic). So bridge will be LAN interface for office and VLAN interface will be where you add hotspot.

Sob - the diagram doesn't show my currently in use (2) Linksys routers. I want to replace them with the hEXs.

I currently have bridged all Ethernet ports on the Mikrotik to the WAN - (1) bridge.

If I setup like you suggest - will my office be protected from the Hotspot?
Tagging Hotspot on (3) AP's? Do all AP's get tagged with the same id? Like VLAN10 or can they have different numbers on each?

Also - what about the IP cameras? Should I use IP bindings through the Hotspot? I really want them on the office network, but how?

Thanks for helping!

The only thought to consider:
hEX S have a very weak switch chip implementation - it can't do vlan's in hardware, only in software.
It is not a real problem for small loads, but depending of the intra-vlan/inter-vlan ratio it can be a good idea to put a more decent switch between hEX and the rest of the network, so only inter-vlan routing is done on the hEX, and all intra-vlan switching is done on a switch.
If the existing Netgear switch is a managed type and if it can be done "geographically", you can rearrange your layout to use it, instead of the extra one.

Code: Select all

    Modem
      |
     hEXs
      |
Managed switch
    / | \
Everything Else

xvo - if a switch would make it better/easier I can get one. Which one do you suggest?

Is the CRS112-8P-4S-IN a good one? - I do need to replace some of these POE injectors on my IP cams.

My Netgear switch is unmanaged.

Thanks

Router routes everything it can, so you need to use firewall rules to block access between networks you want to isolate from each other.

I'd just put all hotspot traffic in one common VLAN, unless there's a reason to do it differently.

And IP cameras depend on your AP, configure it to not put them them in VLAN and they will be part of main untagged office LAN.

The only thought to consider:
hEX S have a very weak switch chip implementation - it can't do vlan's in hardware, only in software.
It is not a real problem for small loads, but depending of the intra-vlan/inter-vlan ratio it can be a good idea to put a more decent switch between hEX and the rest of the network, so only inter-vlan routing is done on the hEX, and all intra-vlan switching is done on a switch.
If the existing Netgear switch is a managed type and if it can be done "geographically", you can rearrange your layout to use it, instead of the extra one.

Code: Select all

    Modem
      |
     hEXs
      |
Managed switch
    / | \
Everything Else

xvo - if a switch would make it better/easier I can get one. Which one do you suggest?

Is the CRS112-8P-4S-IN a good one? - I do need to replace some of these POE injectors on my IP cams.

My Netgear switch is unmanaged.

Thanks

Have no experience using it, but it should do the work.

But once again - it MAY help, if most of your traffic stays inside separate vlans.
If most of you traffic is from LAN to WAN and back, and from one vlan to another, then it won't make real difference.

So I think, you'd better start with just a hEX S, but be prepared to add a switch

Well.....I'm not getting anywhere with the VLAN on Hotspot "working"?

I set my test AP to tag traffic to VLAN 10.

On router all lans bridged (one bridge) > AP plugged into ether4 > I put the VLAN10 ID 10 on ether4 interface > dhcp is on the bridge > bridge VLAN filtering is checked and PVID 1

I'm missing something. Can someone please advise on putting Hotspot on VLAN?

Thanks!

The /interface vlan for hotspot must be attached to the bridge, not to its particular member port. And the IP address, DHCP server, and hotspot configuration for the guest network must all be attached to that /interface vlan, whilst the IP address and DHCP server for the "insider" network stays attached to the bridge as frames carrying the insider network's packets come untagged from the AP. And at this stage you don't need to activate vlan-filtering on the bridge - if you do, you have to set more items.

The /interface vlan for hotspot must be attached to the bridge, not to its particular member port. And the IP address, DHCP server, and hotspot configuration for the guest network must all be attached to that /interface vlan, whilst the IP address and DHCP server for the "insider" network stays attached to the bridge as frames carrying the insider network's packets come untagged from the AP. And at this stage you don't need to activate vlan-filtering on the bridge - if you do, you have to set more items.

THANKS sindy!

I got the vlan off the member port and on the bridge > HS configured to vlan > separate dhcp from bridge for vlan > unchecked the vlan filtering on bridge.

I can get an IP address for my dhcp server/pool. I can not get my HS login page or internet. Ping test works on bridge not on vlan.

Post the current configuration (see my automatic signature below) as you did some changes since you've posted it before, there must be something else wrong.
Other than that, I would first disable everything related to the hotspot (and set some password for the guest SSID on the AP) to check whether the wireless clients connected to both the insider SSID (which I believe comes tagless from the AP) and the guest SSID can get an address and get to internet.

BTW, it may seem that me and @Sob give you a contradictory advice, but it's not like that. @Sob says that /interface vlan can be attached to an ethernet interface if that interface is not a member port of any bridge; I've said that the /interface vlan must be attached to a bridge but that's because you've decided to bridge other ports with the one to which the AP is connected.

Sindy - I appreciate any help from you and Sob contradictory or not. I want to learn!

I'm getting my login page and can login. I got google a couple times and then it's just spinning. I get my status page - saying I'm logged in.

Attached is my embarrassing config file - sorry!

Back to testing.......thanks

First, I haven't opened your previous config so I haven't noticed your firewall is widely open; in contrary to popular belief, NAT alone is not sufficient as a protection against all attacks which can come in via WAN, and it doesn't protect the router itself at all. So have a look at the default firewall in /system default-configuration print; if you want a supercharged intro into how the firewall works, here it is.

If there is a device with firewalling functionality between your Tik's ether1 and your internet uplink, it's a tiny bit less urgent, but you still need to protect the Tik from hotspot clients trying to become its admins.

Second, your only /ip dhcp-server network item provides the hotspot clients with a default gateway address but not with a DNS server address, which makes it impossible for them to translate domain names like www.google.com to addresses like 216.239.36.109. So either add dns-server=8.8.8.8 to that item to make the clients use the Google DNS, or use dns-server=192.168.180.1 to make them use the Tik itself (so translations of popular domain names will get cached on the Tik and you'll thus save some uplink bandwidth), but in that case, you'll also have to set allow-remote-requests to yes under /ip dns and permit access to DNS port from the LAN (hotspot) side in the firewall. Access to DNS via WAN must stay blocked.

Second, your only /ip dhcp-server network item provides the hotspot clients with a default gateway address but not with a DNS server address, which makes it impossible for them to translate domain names like www.google.com to addresses like 216.239.36.109. So either add dns-server=8.8.8.8 to that item to make the clients use the Google DNS, or use dns-server=192.168.180.1 to make them use the Tik itself (so translations of popular domain names will get cached on the Tik and you'll thus save some uplink bandwidth), but in that case, you'll also have to set allow-remote-requests to yes under /ip dns and permit access to DNS port from the LAN (hotspot) side in the firewall. Access to DNS via WAN must stay blocked.

sindy - ok I will incorporate the firewalls once I get the Tik hotspot working on the vlan.

>where do you add DNS server address to hotspot clients on the dhcp-server? /ip dns - My server now is 8.8.8.8 and 8.8.4.4
>I ticked "allow-remote-request"
>can't find - permit access to DNS port from LAN

Thanks

I will incorporate the firewalls once I get the Tik hotspot working on the vlan.

If ether1 gets a public IP, the machine may have already been compromised.

>Where do you add DNS server address to hotspot clients on the dhcp-server? /ip dns - My server now is 8.8.8.8 and 8.8.4.4
>I ticked "allow-remote-request"
>can't find - permit access to DNS port from LAN

The setting of upper tier DNS servers for the Tik itself is one thing, telling the DHCP clients what DNS servers to use is a different one.

With no firewall rules in place, you don't need to use an exceptional rule to accept DNS queries from the hotspot clients.

Other than that, I'm not a hotspot expert and I haven't realized that I should test it before switching off the laptop, but since you configure a reference to the IP pool in the hotspot configuration, I suspect that the hotspot dynamically creates a DHCP server on the interface
you tell it to use, so the manually added one may be redundant or colliding.

I'm still stuck on my one vlan..... I can't get vlan to work.

All I want is to have an office network and a hotspot network on the same Tik router.

I got my AP plugged into ether4 > the AP has (2) ssid > (1) no vlan id and (1) vlan id10 > I can get an ip address on the ssid without a vlan tag and internet. I can't get ip for the vlan10.

I got all lans bridged > vlan is on ether4

What is it with vlans? I'm missing something?

Guessing from your description what may be wrong: you can have one tagless and as many as you want tagged VLANs directly on an Ethernet interface, but if you do it this way, you cannot add the interface itself to a bridge (I mean, you can but the tagged VLANs won't work). So if you want ether4 to be bridged with other interfaces, you have to detach the /interface vlan from ether4 and attach it to the bridge of which ether4 is a member port.

If you do this and it still doesn't work, post the current export again.

Guessing from your description what may be wrong: you can have one tagless and as many as you want tagged VLANs directly on an Ethernet interface, but if you do it this way, you cannot add the interface itself to a bridge (I mean, you can but the tagged VLANs won't work). So if you want ether4 to be bridged with other interfaces, you have to detach the /interface vlan from ether4 and attach it to the bridge of which ether4 is a member port.

If you do this and it still doesn't work, post the current export again.

sindy i hope to get this working - thanks

I moved the vlan to the bridge, but still can't get an ip/internet. I can on open ssid on same AP. AP has static address if that matters.

I have checked > "allow remote request" in dns. Still the same.

Well, except the pvid=10 in the /interface bridge port row for ether4 (which is harmless until you eventually set vlan-filtering to yes), everything seems fine regarding VLANs. However, there is neither any hotspot configuration nor a regular IP configuration attached to /interface vlan vlan-id=10, so no wonder it doesn't give out an address. So set an IP address, IP pool, DHCP server, dhcp-server network etc. (a different subnet from the one you use at bridge1 itself) also for that /interface vlan and only if that works, you can disable the server, keep only the address, pool and dhcp-server network, and set the hotspot referring to the /interface vlan and the pool.

MAN-O-MAN......this thing is WORKING!!!

Both the tagged vlan-id10 ssid and the untagged ssid side works. I also turned on vlan filtering > under bridge > double-click bridge tab and it works, but will uncheck for the rest of my config is done.

I guest you noticed I had the Protocol Mode > none. Is that ok?

Now I need to config HS on the vlan10 and other AP's. Should I config the other AP's as a different vlan-id or keep the same id10?

Thanks, so much, this was making crazy! You're GOOD sindy!

I also turned on vlan filtering > under bridge > double-click bridge tab and it works, but will uncheck for the rest of my config is done.

vlan-filtering requires more settings to be done to work properly, as @pcunite explains here. For your scenario it is not actually needed unless the Ethernet ports are physically exposed to random passers-by.

I guest you noticed I had the Protocol Mode > none. Is that ok?

It is OK as long as you keep your network topology free from redundant links between the boxes. Once you'd wish to provide some resilience, you'd have to think about STP and you'd have to change the protocol-mode of the bridge.

Now I need to config HS on the vlan10 and other AP's. Should I config the other AP's as a different vlan-id or keep the same id10?

To keep it simple I'd stay with the same VLANs on all APs. You probably want your guests and colleagues to roam as seamlessly as possible among the APs, so you need them to stay in the the same IP subnet and keep the same IP address, which implies a common VLAN for the same SSID on all APs.

Good answers sindy.......

I got to put in firewall rules to separate the vlan from the office. Can you give me direction?

I like your firewall link above and it will help.

I got to put in firewall rules to separate the vlan from the office. Can you give me direction?

A firewall provides the best protection if it drops everything by default and only lets through exceptions you want to let through. The firewall rules provided in the default configuration of the hXX product line of Mikrotik do exactly that, but with some optimisation which complicates readability. So instead of three simple rules
action=accept in-interface-list=WAN connection-nat-state=dstnat
action=accept in-interface-list=LAN
action=drop
there is a single complex one in chain=forward of /ip firewall filter:
action=drop in-interface-list=WAN connection-nat-state=!dstnat
The effect is the same as long as you only have two logical groups of interfaces (or zones) - the WAN one(s) and the rest.

In your case, you have three zones - the internet (represented by interface-list WAN), the internal network for you and your colleagues/employees, and the network for customers/guests. So as for chain=forward, which deals with traffic passing through the Tik, using the "what to forbid" thinking, you basically need that

• no connection can be initiated by a host in the internet towards a host in any of the two internal zones
• no connection can be initiated by a host in the zone GUEST (represented by the /interface vlan vlan-id=10) towards zone STAFF (represented by /interface bridge name=bridge1) and probably vice versa (no reason for your staff to connect to guests' devices).

The rest is allowed.

But the same can be also viewed from the "what to permit" perspective, and that way it is even simpler:

• permit anything from GUEST or STAFF to initiate connections to WAN

The rest is forbidden.

As we talk here about a stateful firewall, the detailed rules only deal with the initial packet of each connection; if we permit it, the first two rules saying "fasttrack whatever belongs to already existing connections or is related to them" and "accept whatever belongs to already existing connections or is related to them" take care about the rest of the connection.

So without optimisation, you would rename the existing interface-list LAN to STAFF, create another interface-list named GUEST and make the /interface vlan vlan-id=10 a single member of it, and then replace the very last rule in chain=forward by the following three ones:
chain=forward action=accept in-interface-list=STAFF out-interface-list=WAN
chain=forward action=accept in-interface-list=GUEST out-interface-list=WAN
chain=forward action=drop

Optimisation is possible due to the fact that the handling of STAFF and GUEST is actually the same - both can connect to external servers via WAN but cannot establish connections to each other. So you can use just two rules (and don't need to modify and add any interface-list):
chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
chain=forward action=drop

But bear in mind that "optimisation" and "simplification" are not synonyms. Less rules mean less CPU load (so optimisation), but more brain load when you try to understand what you did 3 months ago, so not necessarily a simplification from this point of view.

As for chain=input, it controls access to your Tik itself. But there are three types of services awaiting connection:

• actual services for clients, such as DNS or NTP
• network control protocols, such as ICMP, VRRP, OSPF and others
• management of the router itself

Given that cross-platform malware exists these days, it is best to prevent access to management of the router even for the STAFF zone. So creating yet another IP subnet and attaching it to a dedicated Ethernet interface removed from the bridge is the second safest way (the first one being to manage the device via serial console and completely disable access to management services from any zone).

But you need to permit access to DNS if you want to run it on the router.

So instead of the last rule in chain=input of the default firewall, chain=input action=drop in-interface-list=!LAN, the following is the minimum:
chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=22,443,8291 in-interface-list=LAN src-address=ip.of.your.laptop
chain=input action=drop
53 is a port for DNS; 22, 443, and 8291 are SSH, HTTPS, and Winbox ports, respectively. To make https management possible, you need to generate a certificate and bind it with the "www-ssl" service. What in-interface-list and/or src-address you choose to permit access to the management services depends on your decision, and you have to configure the rest of the system accordingly (assigning an IP address to the management laptop manually or creating a reserved DHCP lease for it are necessary to use src-address in this rule, setting up a dedicated interface and a subnet attached to it for management purposes is necessary to use in-interface(-list) as the only restriction in this rule).

Also bear in mind that Winbox can connect to the machine also using MAC address, so completely bypassing the L3 firewall. The access using MAC-Winbox and MAC-telnet is controlled by an interface-list you set as a value of allowed-interface-list under /tool mac-server. So also here, the "second safest" approach is to create a dedicated interface-list such as MAC-MANAGEMENT, put to it a single Ethernet interface not connected to any bridge, and set it as the value of the allowed-interface-list mentioned above.

As you want to use hotspot: it adds rules to the beginning of chain=input and chain=forward to prevent unautenthicated users from reaching the rules of the common firewall and to let them access the hotspot authentication service even if access to it is not permitted in the common firewall. As long as the hotspot user gets authenticated, it is only a matter of your common rules where they will get.

Before adding the hotspot, I'd recommend you to remove the /ip address, /ip pool, /ip dhcp-server, and ip dhcp-server network (which you've used for testing) from /interface vlan vlan-id=10, as well as any existing configuration in the /ip hotspot tree, and then run the /ip hotspot setup wizard which will do all that for you from scratch and interlinks the configuration elements properly.

WOW Sindy!
Great advice! I'm reading your detailed comments several times to understand and learn. It's deep thinking for my setup with good protection.

I'm starting the config.....

Thanks for your time > it's helping > creates feelings of accomplishment

Sindy
Your post makes me question is this the right way to go? Meaning - should I have all these zones on (1) router? Should I do this on (2) routers?
It seems very lengthy to config on (1) router and maybe not at my Tik level knowledge. I can't mess this up and leery about bleeding.

I have (2) ISP's - (1) cable 50meg down and (1) AT&T U verse 25meg down
MAYBE:
-(1) Tik for the office side on my spare U verse ISP I'm not using.

-(1) Tik on my currently used ISP for the Hotspot.
BUT - my IP cam is on one of my AP's. I guess I could wallgarden the IP cam's mac in the HS?

What do you think?

Too late down here to think anything deep, but:

I'd definitely wallgarden static equipment like seccams using a dedicated subnet+VLAN (+SSID if they are wireless) rather than hotspot, using their own dedicated zone.

As for too many zones on one device - I'd use the primary ISP for everything and the other one as a backup just for the office, that's slightly beyond just firewalling but still doable later on.

I don't think the two additional rules in forward in the minimum variant I've suggested are too complex, but I think you really should protect the Tik (or any other router) from unauthorized access from LAN side regardless whether you'll use a single one for both zones (or all three if you take my advice regardiing the seccams) or whether you'll use one per each zone. So read something about safe mode and how to use it, and whenever you add a rule which may potentially lock you out, don't disconnect the current management connection and try to establish another one; if you succeed, that rule didn't lock you out and you can proceed. Safe mode helps you if you cut the running management session, but if you don't, the rule you've added may prevent new session from being established, so that's two separate scenarios to bear in mind.

Yea - Safe Mode is nice and I use it.

I guess the firewall rules you listed confused me....

My testing in safe mode:
-It works on the first rule, but when I config the second rule the internet quits. Is the second rule a rule by itself?
chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
chain=forward action=drop (where does this rule go)

It would be nice to config all on (1) router with a backup ISP for the office (great suggestion sindy).

I like all your advice.
I understand and learn better if I see 1. do this, 2. do this, 3. do this, etc...

Sindy - I think what your recommending is: I would like my network all on the Tik.

For the 3 zones (wan, office, hotspot). It's not to complex, just takes me time to understand.....

The Firewall filters: (with interfaces - as is - OFFICE/interface bridge name=bridge1 > HS/interface vlan vlan-id=10
(forward chain)
chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
chain=forward action=drop
The above rule separates the zones > If I understand the rule, it only allows all interfaces internet connection and drops everything else.
OFFICE clients can connect to each other?
(when I do the last rule above - the internet isn't available)

(input chain)
"I also need remote management" and to generate a certificate for https and bind - I will need some direction (I guess OpenSSL?)
Note: I could just remote into the management computer and open winbox and usermanager.
chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=22,443,8291 in-interface-list=LAN src-address=ip.of.your.laptop
chain=input action=drop

SO:
1. Leave interfaces as is - all on (1) bridge
2. Hotspot on valan=id10 (I have created the HS on vlan id10 and it's working)
3. Add above firewalls
4. Use MAC-MANAGEMENT
5. ? - Serial console maybe a little extreme for me at this point, but great idea.
6. ? - https management - generate a certificate and bind it with the "www-ssl" service
(what's the best way of doing this ssl cert.)

Please advise...thanks.

chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
chain=forward action=drop
The above rule separates the zones > If I understand the rule, it only allows all interfaces internet connection and drops everything else.
OFFICE clients can connect to each other?

Clients in the same IP subnet send traffic to each other directly at L2, so this traffic bypasses IP firewall rules (unless you'd use special measures to force it through it, which you obviously don't).

(when I do the last rule above - the internet isn't available)

If you have only these two rules in chain=forward, it's no surprise that the second one breaks internet access, because the first one only permits packets to flow in LAN->WAN direction, but not in the opposite one. So you have to add chain=forward connection-state=established,related as the very first rule in chain=forward. This rule will handle most traffic in both directions, only the initial packet of each new connection will get past it and be handled by one of the two other ones.

"I also need remote management" and to generate a certificate for https and bind - I will need some direction (I guess OpenSSL?)

There is a tutorial on Mikrotik wiki on how to create a certificate and use it. Nothing complicated about it.

Note: I could just remote into the management computer and open winbox and usermanager.
chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=22,443,8291 in-interface-list=LAN src-address=ip.of.your.laptop
chain=input action=drop

Here, the chain=input action=accept connection-state=established,related rule just speeds things up. As chain=output is empty, the response packets of the system are always let through, but the rule I've mentioned will make sure that mid-connection packets from the management PC will not have to be checked by all the rules preceding the one which matches and accepts them.

Sindy - I'm starting to slowly understand, sorry. See if I'm on the right track and If I need more rules?

/ip firewall filter
add chain=forward connection-state=established action=accept \
comment="allow already established connections"
add chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
add chain=forward action=drop

/ip firewall filter
add chain=input connection-state=established action=accept \
comment="Allow Established connections"
add chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN
add chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN
add chain=input action=accept protocol=tcp dst-port=22,443,8291 in-interface-list=LAN src-address=ip.of.your.laptop
add chain=input action=drop

THANKS for your help!

Seems fine to me. However:
- if you haven't yet, don't add the last drop rule in the input chain before you check that the rule allowing management access counts your connection attempts (I don't know which of the management protocol you use out of ssh / https / winbox); on the other hand, you should not have connected the device to internet before that drop rule could be added
- add "related" to "established" to the first rule in each chain. Without it, e.g. icmp informing about insufficient MTU somewhere along the path won't pass through which causes unnecessary headache.

Sindy
I haven't configured and tested the rules yet. I wanted your input first. I use winbox. I added ",related" after established.

Are you thinking I need to add this first:
These and any other rules in the input chain must be prior to the drop all rule, the most important input rule being
add action=accept chain=input comment="ADMIN ACCESS TO ROUTER" \
in-interface-list=LAN src-address-list=adminaccess
(one creates the adminaccess list in /ip firewall address lists)

Thanks

Well, as you've stated you could not access internet after you've added the forward rules without the "accept established or related" one, it means you did connect the router to internet before securing the management access to it using the input rules. So it can be compromised by now as it has spent some time connected to the internet with management access open to anyone. The automated search bots are bloody fast to spot potential targets.

Hence the proper way to proceed now would be to export (not backup) the configuration, download the .rsc file with the export, check it for presence of any scripts you haven't added yourself, use the "netinstall" tool to clearly install the router overwriting any filth which may squat there by now (scripts added into the configuration are just one possible type of infection), re-create the configuration from the export, create a new user with group=full and with a new password, log in as that user, disable the default user admin, implement the firewall rules in chain input (without the last "drop" one), check that the one you've stated above increases packet count as you connect using Winbox, and then add the final drop one and check again. If you don't get in, you have to connect to the MAC address rather than IP address using Winbox and check what's wrong. And only after doing all that, it is the right time to connect the machine to internet. But again, before you connect any client to it, the rules in chain forward have to be set up to prevent something to reach to the LAN (which is, however, much more complex to effectively exploit than unprotected management access, given that there are private IPs on the LAN).

Sindy - I haven't done any firewall config yet. I did try the drop all rule and it disconnected the internet, but you cleared that up.

Also my Tik is running off a Netgear switch connected to the lan on my Linksys router. My Tik is getting its ip from the Linksys.

I'm just testing for now. Trying to make the correct config for my Tik.

I was just asking about creating secure Tik management, thinking I may lose connection.

I have not been compromised.

If the Tik was behind an external firewall, it's OK, no need to netinstall.

The rest remains - add the last drop rule in input after checking that the one permitting management access from a dedicated interface with a dedicated subnet counts packets. It will count just one packet per each connection, the other packets of each connection will be handled by the "accept established or related" one.

If the Tik was behind an external firewall, it's OK, no need to netinstall.

The rest remains - add the last drop rule in input after checking that the one permitting management access from a dedicated interface with a dedicated subnet counts packets. It will count just one packet per each connection, the other packets of each connection will be handled by the "accept established or related" one.

I added the input drop rule and management works great from my dedicated laptop with static ip. Disabled drop rule and packet count increased by 1 per connection.
Tried to access from another computer on the wan side and it blocked winbox. I disabled the input drop rule and the wan side pc could open winbox with the Tik's ip address. The wan side computer can access winbox by mac address either way with the drop rule.

Hotspot is working good.

How would you TEST? HS access to office lan. etc...

CURRENT FIREWALL RULES:
/ip firewall filter
add chain=forward connection-state=established,related action=accept \
comment="allow already established connections"
add chain=forward connection-state=invalid comment="drop invalid" action=drop
add chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
add chain=forward action=drop

/ip firewall filter
add chain=input connection-state=invalid action=drop \
comment="Drop Invalid connections"
add chain=input connection-state=established,related action=accept \
comment="Allow Established connections"
add chain=input action=accept comment="ADMIN ACCESS TO ROUTER" \
in-interface-list=LAN src-address-list=manager
add chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN
add chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN
add chain=input action=accept protocol=tcp dst-port=22,443,8291 in-interface-list=LAN src-address=192.168.180.100
add chain=input action=drop

Thanks, Sindy

I switched all my AP over to the Tik and the hotspot (HS) is working.

My problem is the last drop rule in the input chain. "Drop everything else"

If it's enabled > logging into HS > I get radius server error and can't login. Disable - allows me to login.

I have included my config file - please let me know what you think?

I'm afraid this may be because one process on the Mikrotik wants to connect to another process (most likely, Radius). To check that, place an action=log chain=input before the last action=drop one, keep the drop one in place and see what the log one catches /log print where topics~"firewall". Then we'll have to create a permissive rule for that. This process may require multiple iterations.

Sindy - good thinking....I like the log check. "See Attachment"
Thanks

Sorry, a busy day today.

If you haven't figured out yourself yet, add a rule chain=input src-address=127.0.0.0/8 dst-address=127.0.0.0/8 action=accept before the final chain=input action=drop one and you should be good.

Sindy - I didn't have it figured out, but makes good sense after seeing and thinking about your response.

I added your new rule and it worked!

You have really helped me and I appreciate all the instructions.

I have my system running well, just for the hotspot off my extra AT&T ISP. I won't make the full switch until after Labor Day.

Usermanager is nice, but takes some time making it work right.

I like this Mikrotik stuff and want to learn. My PHP and HTML coding I like, but this is way more fun.

Ok - things are working, except......port forwarding.

Please look over my firewall/nat rules and advise.

I want internet access to webfig, so I added the following and it works, hope it's right. IP Cloud - enabled and the Tik's ddns address takes me to webfig login.
add action=accept chain=input comment="WEBFIG ACCESS for Internet" \
dst-address-list=Wan_IP
I'm also able to access usermanager by the public IP with (public ip)/userman - I like that.

BUT....
I can't get port 27270 to my IP camera to port forward after many many configs? I added a static route and the IP cam has a static IP. I can access the cam via the lan, but not from the internet. I have the main AT&T router in IP passthrough mode and the Tik shows a public IP.

Look at this page.

For received packets, dst-nat handling takes place before routing, i.e. before taking the decision whether the packet is for the router itself or to be forwarded outwards. So once dst-nat rule diverts the received packet from its original dst-address (of the WAN interface) to the LAN address of the camera, it is handled by the forward chain, not the input one. So move the permissive rule in /ip firewall filter from input to forward, replace dst-address-list=WAN by by dst-address=ip.of.the.camera and you should be good. Or you may use a single generic filter rule for port forwardings - action=accept chain=forward connection-nat-state=dstnat in-interface=ISP. It would be a nonsense to configure port forwarding in the dstnat chain and then not accept the forwarded packets in filter, so the usual approach is to concentrate all match conditions (including source address matching) into the individual action=dst-nat rules and to use this single generic rule in filter.

Nice! - Sindy

What a chart........great info.

I did go back and watch all my /ip firewall filters while trying to connect with the cam and the very last rule in the chain=forward was killing the packets. I disabled it and that allowed the packets to flow (cam connection), so I knew it was something in the forward chain.

I enabled my last chain=forward drop rule and used your single generic filter rule. It's working.

My learning is expanding - thanks Sindy

All has been good up until now - any advice on dealing with PCI Compliant scans?

My current set-up is failing the scans.....See attached scan Vulnerability Details

I think we discussed this earlier. It is not enough to disable access to management and/or file transfer services (SSH, telnet, http, FTP) only from the WAN side but also from the LAN side of your router devices, leaving them accessible only via dedicated physical interfaces and from dedicated source addresses, especially in your application scenario where the LAN interfaces are made available to 3rd parties. The wording of the vulnerability descriptions is quite misleading in some cases - e.g. telnet and FTP accept plaintext passwords simply because they don't support any other methods of user authentication than plaintext password. But nowadays there is no reason to use telnet when SSH is available on the machine, except if you operate the system in a jurisdiction which prohibits ciphered communication (such ones do exist, and technically they make any visitor of a https site a criminal, but that'd be an off-topic discussion).

So first, do your PCI scan from the WAN side to see whether it will will report any vulnerability - it should not unless you've changed the rules in chain=input of your /ip firewall filter since you've posted your configuration here last time. Next, set up a dedicated management interface and permit, as an exception from the general firewall rules, access to the management services you need to use from that interface, so that you could forbid it in the general rules. I've already suggested before how to do this.

After this, the PCI scan from the publicly accessible LAN interfaces (presumably only the wireless ones will be publicly accessible) should also not show any vulnerability.

Those vulnerabilities which remain when testing via the dedicated management interface cannot be resolved by means of configuration, as you cannot change e.g. the fact that some files are accessible via http. But there is no real reason to keep http accessible even via the dedicated management interface as you can set up https access instead. On the other hand, https as such does not prevent unauthorized access to some files - the application needs to be written properly so that such access would not be possible without a prior authentication. So even if you disable http and permit only https, the PCI test may still show this kind of vulnerability if some files can be accessed by non-authenticated users. If it does, it's only Mikrotik developers who can fix this.

Same case is use of key algorithms considered weak on SSH and/or HTTPS interfaces. Definitely set use-strong-crypto to yes in /ip ssh settings, but if even in that case the PCI scan complains about weak key algorithms, it's up to Mikrotik developers to fix that by adding those considered strong according to state-of-the-art and disabling all weaker ones when use-strong-crypto is set to yes.

The most mysterious part for me are the complaints that some ports like 111 or 37779 are open at all. But again, once you disable access to these ports using the firewall, you don't need to care.

And of course, if you connect an infected PC to the dedicated management interface, the malware can deploy any of the vulnerabilities of the management services which are set to be accessible via that interface, but on an infected PC you cannot be sure that you keypresses aren't logged and used later to access the management services later with the correct credentials.

Thanks for your long response - Sindy

I did make some changes:
I left the hotspot on the hEXs on my cable ISP. No problems for now.
I bought a hap ac for the office network and put it on my uVerse ISP. Current PCI Complaint scan fails.

My scans are executed from the wan side by the ControlScan company. I login to their site and setup the scan. They email me the results - Pass or Fail.

I have several ports open for my cams 37779, 36200, etc. I don't know what the 111 ports is?

>>>>I'm not at the router location at this time. >>>>I config via winbox logging in by the Mikrotik ddns. So I don't want to loss my connection to the router >!
>What ports are needed for my ip cloud ddns to keep working???

I tried this "How to block port scanner in MikroTIk"https://monovm.com/blog/how-to-block-po ... -mikrotik/, but I may have done it wrong or it just doesn't work. I did forget to create the "scanner list" under address list before the scan. I don't know what to put in the address field when creating the "scanner list" What's your opinion of this method?

Please advise knowing more about my current configuration. I have attached my new config file.

I won't open my laptop right now just to study your configuration, but if FTP and telnet are accessible from internet, you must have ignored my suggestions given earlier regarding how to build the firewall (drop everything except what you absolutely need to be accessible from the internet). Telnet and FTP do NOT need to be accessible from outside. If they were accessible from the internet for some time, there is no guarantee that the machine has not been hacked during that time.

So the only way to make sure that the machine is safe is to disconnect it from the internet, export the current configuration into a file, inspect the file thoroughly, remove any scripts you haven't added yourself, disable any services you haven't enabled yourself, netinstall the machine, and paste the sanitized configuration back line by line. Then redo the firewall so that it doesn't leave plaintext management interfaces accessible, and only after doing this, connect the machine back to the internet. If multiple Mikrotik in the network were accessible from each other, you must isolate them from each other, do the procedure above on each one separately, and only then connect them together again.

It's not paranoia, it's mere experience.

As for ports 3xxxx open to cameras, this means that the PCI scan findings regarding these ports are relevant to the cameras, not the Mikrotik itself.

If you need to access the cameras for your own purposes only, a VPN is your best option, making the access to them authenticated in a secure way. If you need to make them accessible to the public, you'd need an L7 firewall to sanitize the traffic, in order to prevent the cameras from becoming malware sources for the visitors, or to replace them by models which are safe themselves. Mikrotik configuration can only be used to prevent an infected camera from attacking your LAN, but not to prevent the camera from getting infected via the vulnerabilities of its embedded http server and from spreading that infection to clients which visit that embedded server. I've heard of products which provide L7 firewall functionality but I have no hands-on experience with them so I cannot give you particular recommendations.

To use any kind of DDNS, you don't need to permit access from outside to any port of your Mikrotik - all the communication necessary to update the DNS information whenever the IP address changes is initiated by the Mikrotik itself. But do not consider the winbox communication a 100% secure one, vulnerabilities have been discovered in the not-so-distant past. So if you cannot restrict access to winbox port to just a few known addresses, use a VPN as an additional layer of security.

I now have ftp and telnet disabled. I don't see any scripts that I haven't done and my logs are ok.

What about ssh?

I think on the port 111 > I will try:
add chain=tcp protocol=tcp dst-port=111 action=drop \
comment="deny RPC portmapper"
add chain=udp protocol=udp dst-port=111 action=drop comment="deny PRC portmapper"

My cams are me only - so I will look into a vpn solution. I don't have time to learn vpn and get that done.
Although - I NEED to pass my scan NOW.
I guess I will disable the cam ports and run the scan for now.

I still need to handle port 80? (maybe disable 80 for the scan) and I hope my above port 111 solution will work.

Thanks again

I don't see any scripts that I haven't done and my logs are ok.

Malware scripts and enabled services are just the visible top of the iceberg. More advanced malware lives below the RouterOS wrapper of linux so it remains invisible from the RouterOS level in both configuration and logs. By netinstall you remove everything because the flashdisk is completely erased, but you remove also the configuration, so you need to save it before netinstall and then restore it. So the advice regarding the inspection of the exported configuration addresses solely this save and restore process. The most important part is the netinstall.

What about ssh?
...
My cams are me only - so I will look into a vpn solution. I don't have time to learn vpn and get that done.

You can see SSH as the least complicated kind of VPN - if you enable SSH tunneling at Mikrotik and in PuTTY, you can log in using SSH (so the SSH port may be the only one open for access from the internet) and then use Winbox via the tunnel instead of the command line in SSH itself. The same can be done for the cameras - you set the tunnels in PuTTY from a local port on the client PC to internal address:port of the camera and you're done.

I think on the port 111 > I will try:
add chain=tcp protocol=tcp dst-port=111 action=drop \
comment="deny RPC portmapper"
add chain=udp protocol=udp dst-port=111 action=drop comment="deny PRC portmapper"

Once again - DROP exceptions from a general ACCEPT strategy are a wrong idea. The correct approach are ACCEPT exceptions from a general DROP. You're not an ISP, you're a client network, so there is no reason why access to your LAN and to the router devices themselves should be generally open. Your WiFi clients won't bring their servers to run them in your network and expect requests from clients from the whole world to get through to them.

Although - I NEED to pass my scan NOW.
I guess I will disable the cam ports and run the scan for now.

Well, to pass the PCI scan to five stars, the best way is to disconnect the device from internet and run the test, but a purpose of such action is beyond my understanding. What's the sense in passing the scan once under specially created conditions? Remember Dieselgate

I still need to handle port 80? (maybe disable 80 for the scan) and I hope my above port 111 solution will work.

There is no reason why Mikrotik's own port 80, and ports 80 of hosts on your LAN, should be accessible to clients in the internet. What you only need is that port 80 of servers in the internet is accessible to clients connected in your LAN, and that's a different task and different corresponding setup of the firewall.

Sindy THANKS - I owe you a coke, beer, wine, whisky, meal.

I got my VPN working. >Quick Set> >check VPN Access> "not sure if this is the right way or right vpn, but very easy"
I don't have internet service when VPN is connected. I can connect to my cams through the browser. I can't figure out how to connect to the router config by winbox through the VPN?

My next scan failed only for port 111 and 46204 which wasn't on the first scan. 46204 is AT&T's random remote management port which I disabled for this next scan.

The reason to get the scan to pass ASAP is because they charge a NON-PCI Compliant fee. I get the scan pasted and that gets me 90 days to figure out a solution until the next scan.

Before disabling telnet - I see several attempts in my Log of login failure.

I disabled port 80 - the only thing enabled is api, api-ssl and winbox. I'm not clear, if I should disable these mentioned ports.