Hi,
with the help of many nice forum members, I managed to get VLANs working on my Mikrotik HapAC2 router.

We described the solution in this post: viewtopic.php?t=188058
The solution is based on this post: viewtopic.php?t=143620

However, I found a problem that I could not solve.

According to the settings, in principle, the router could only be accessed using WinBox at IP address 192.168.5.1 from the BASE VLAN. However, from any VLAN (BLUE, GREEN) I can reach the router the IP address 192.168.1.254 of the BLUE_VLAN . It seems that there is no separation between VLANs.

What could be the problem? What config should I copy?

Could someone help me?

For the Nth time ...

If one observes packet flow in ROS, one can notice that one of earliest actions performed is connection tracking classification. Which then provides information about which firewall chain the packet enters in further stages. When a packet's destination IP address matches any of router's own addresses, it's entering input chain and ingress interface doesn't change the classification result.
Now ... firewall filter rules (or firewall raw rules) can drop packets targeting router itself but ingressing via "alien" interface, but firewall admin has to construct them.

Personally I don't think this kind of filtering improves router's security in any way, it's pure cosmetics thingy. If it bothers somebody, then it's easy enough to block it. I just won't provide cook book code for useless configuration.

Duplicate NM

I dont give a crap about your references, what is needed is your full config here.....!!!!
(minus any public WANIP info of course).

Comments:

FIREWALL RULES SUCK, in a number of way.
- First disorganized and thus hard to follow, put all input chain rules together and then forward chain rules. Better for all!! \
- get rid of the crap rules............
- stick to default type rules and clean/clear rules

Fixed below........ order counts within a chain as well.
NOTES:
(1) This rule I could not make heads or tails of especially as there is no subnet on the router that I can see (192.168.0.0/24)......... Please let us know what the intent of this rule actually is, from the user perspective.
add action=accept chain=input comment=\
"Accept all from LAN works with drop input" in-interface=BR1
add action=accept chain=input comment="Accept ssh to subnet" dst-address=\
192.168.1.0/24 dst-port=22 protocol=tcp src-address=192.168.0.0/24

IF this is indeed an ipsec address or subnet you have given your vpn then this should be in the FORWARD chain as it appears you want people coming in on ipsec to be able to access the BLUE VLAN ???

(2) These rules I could not make heads or tails of as you appear to be giving access from one thing to itself and is the case for both rules actually. ?????????????
add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \
dst-address=192.168.1.0/24 in-interface=all-ppp src-address=\
192.168.1.0/24
add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \
dst-address=192.168.1.0/24 out-interface=all-ppp src-address=\
192.168.1.0/24

(3) This rule is TOO wide open, it has no destination detailed.......
add action=accept chain=forward in-interface=BR1 src-address=192.168.1.0/24 missing dst-address? dst-address-list? out-interface? out-interface-list?

(4) This looks like a destination NAT rule and not a port forward rule!!
add action=accept chain=forward dst-address=10.0.20.2 dst-port=1195 \
in-interface-list=WAN protocol=udp

(5) This rule make no sense to me............ you are again allowing BLUE VLAN to be accessed by WAN, sounds like destination NAT.
add action=accept chain=forward comment="forward openVPN to Zentyal" \
dst-address=192.168.1.1 dst-port=1196 in-interface=pppoe-out1 protocol=udp

also in one rule you use wan interface list, here you use the actual interface why the inconsistency??

(6) I left out this rule on the input chain as well, as I dont see its purpose, it appears to be very non-standard................???
add action=accept chain=input comment="Site2Site VPN" dst-address=\
XXX.XXX.177.63 in-interface-list=WAN src-address=XXX.XXX.43.161

(7) Suggest your remove this setting as your IP DHCP Client is handled by PPPOE settings!!
/ip dhcp-client
add interface=ether1

(8) I am not very familiar with how to source nat your LAN traffic going out the ipsec tunnel but this does not appear correct to me. I appreciate it mirrors your ipsec policy though!!
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.0.0/24 src-address=\
192.168.1.0/24

Perhaps use out-interface=vpn or out-interface=isipos ??? I am out on left field on this one.

(9) DST NAT RULES are not consistently applied.
I see you two rules missing the standard dynamic IP in-interface-list=WAN while the other two use a static IP approach which is not correct for pppoe unless its a static IP??? ( dst-address=94.21.....)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Summary: This should be a starting point, If you are still having issues then lets tackle your mangle rules next. Why do you need them??

Dear @anav, thank you for helping again.
I would like to ask if I should simply leave the other /ip firewall filter rules? I have 45 /ip firewall filter rules...

Isn't that a mistake? What would be correct?
"add action=drop chain=input comment="Drop all else"[/b]
{forward chain}"

(1) This rule I could not make heads or tails of especially as there is no subnet on the router that I can see (192.168.0.0/24)......... Please let us know what the intent of this rule actually is, from the user perspective.
add action=accept chain=input comment=\
"Accept all from LAN works with drop input" in-interface=BR1
add action=accept chain=input comment="Accept ssh to subnet" dst-address=\
192.168.1.0/24 dst-port=22 protocol=tcp src-address=192.168.0.0/24

There is a Site-to-site IPSec VPN between my office and home. Both locations have Mikrotik HapAC2 routers. The IP address range of the office network is 192.168.0.0/24 to the home 192.168.1.0/24 (BLU_VLAN). This rule ensures that all devices in the two networks see each other and can connect to each other.

(2) These rules I could not make heads or tails of as you appear to be giving access from one thing to itself and is the case for both rules actually. ?????????????
add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \
dst-address=192.168.1.0/24 in-interface=all-ppp src-address=\
192.168.1.0/24
add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \
dst-address=192.168.1.0/24 out-interface=all-ppp src-address=\
192.168.1.0/24

In addition to the Site-to-Site VPN, the client has an L2TP/IPSec VPN for remote work.These rules would direct traffic from the L2TP/IPSec remote client into and out of the BLUE_VLAN.

(3) This rule is TOO wide open, it has no destination detailed.......
add action=accept chain=forward in-interface=BR1 src-address=192.168.1.0/24 missing dst-address? dst-address-list? out-interface? out-interface-list?

This rule originally routed traffic to the 192.168.1.0/24 network, now routes it to the BLUE_VLAN. There was also another subnet, but not as a VLAN, but I don't use it anymore. Now this other subnet would be the GREEN_VLAN to which I would connect a server.

(4) This looks like a destination NAT rule and not a port forward rule!!
add action=accept chain=forward dst-address=10.0.20.2 dst-port=1195 \
in-interface-list=WAN protocol=udp

This would be openVPN port forwarding to the server placed in GREEN_VLAN for direct connection.

(5) This rule make no sense to me............ you are again allowing BLUE VLAN to be accessed by WAN, sounds like destination NAT.
add action=accept chain=forward comment="forward openVPN to Zentyal" \
dst-address=192.168.1.1 dst-port=1196 in-interface=pppoe-out1 protocol=udp

Similar to (4), this is openVPN port forwarding to the Zentyal server, which is located in the BLUE_VLAN...

"also in one rule you use wan interface list, here you use the actual interface why the inconsistency??"
What do you suggest? What should I use WAN or ether1 or pppoe designation? Isn't it easier to refer to WAN?

(6) I left out this rule on the input chain as well, as I dont see its purpose, it appears to be very non-standard................???
add action=accept chain=input comment="Site2Site VPN" dst-address=\
XXX.XXX.177.63 in-interface-list=WAN src-address=XXX.XXX.43.161

This rule ensures Site-to-Site VPN connectivity between public static IP addresses.

(8) I am not very familiar with how to source nat your LAN traffic going out the ipsec tunnel but this does not appear correct to me. I appreciate it mirrors your ipsec policy though!!
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.0.0/24 src-address=\
192.168.1.0/24

Without this rule, the two networks cannot be traversed, there is no traffic between them, they cannot see each other. Do you have a better solution for this?

"Perhaps use out-interface=vpn or out-interface=isipos ??? I am out on left field on this one."

Sorry, but I don't understand what you mean here. vpn and isipos are not interfaces, but login names used for L2TP/IPSec connection under /ppp secret...

(9) DST NAT RULES are not consistently applied.
I see you two rules missing the standard dynamic IP in-interface-list=WAN while the other two use a static IP approach which is not correct for pppoe unless its a static IP??? ( dst-address=94.21.....)

The public IP address is a static IP address at both locations...


I would like you to understand what I want to achieve, what my goal is with this design. If this setting works well, I would like to develop it further.
The goal would be to have a BLUE_VLAN with 1-2 ethernet and a 2GHz and a 5GHz WiFi for the devices that can be connected remotely with L2TP/IPSec VPN and the office and my home network are connected by IPSec VPN with.
There would be an independent subnet (like the DMZ) GREEN_VLAN with an ethernet port to which the public server would be connected and from the outside it would be possible to connect to the server with openVPN running on the server for remote work.
There would be a 2GHz WiFi ethernet port (PURPLE_VLAN) for guests as a separate subnet.
Finally, there would be a separate ethernet port to manage the router without WiFi or with WiFi, this should still be considered as an independent BASE_VLAN subnet.
If everything works fine on the home router, I have to "reprogram" the office ones as well.

Thank you very much for your help.
Thanks and Regards

Today I managed to configure the router according to my expectations. Thanks to @anav for the help.

I created three VLANs.
The first one for local network purpose called BLUE with three Ethernet ports and 2 GHz and 5 GHz WiFi.
The second named GREEN for the server as a DMZ with an Ethernet port.
The third is for guests only as a 2 GHz WiFi network.

The configuration also includes a site-to-site IPSec VPN between two locations and an L2TP/IPSec VPN for remote work. In addition to these, it contains additional configuration for the openVPN connection running on the server and the operation of the VoIP server.

The firewall rules had to be worked on to make everything work well. I will attach the config tomorrow and please write your comments to make it the best it can be.
If someone wants to make their own based on the config, they can use the config.

The next step for me will be to reconfigure the office router in a similar way. I'm going to sleep now...

Thanks for your help so far.

I attached an sample config for Mikrotik VLANs. This config works Mikrotik Hapac2 router and I can't guarantee that it will works correctly other Mikrotik router. I created this for my own purpose but everyone can modify it for their own purpose according to their own needs.
This config includes example:
three VLANs
BLUE for local network ethernet and 2 és 5GHz WiFi
GREEN for DMZ ethernet for server
BASE for only Guest WiFi
L2TP/IPSec VPN for remote client for admin
Pass trough openVPN to server for teleworker
IPSec Site-to-Site VPN for remote site
pppoe internet connection
asterisk mangle rules for VoIP on local network
firewall rules for bogon list, port scanning and ssh blacklist

Don't use this config for import directly your router!
You need to change some specific parameters in config before you try to upload your router! Eg. user names, passwords, IP addresses, MAC Addresses, etc.

@pcunite's topic provided a lot of help in creating the config: viewtopic.php?t=143620&sid=ebd84249c28f ... 3d83c1fdd3
The forum members also helped a lot in this topic: viewtopic.php?t=188058

Special thanks to @anav for your the help.

Thanks and Regards

Hi Steve, what is the purpose of the BASE VLAN. If you are stating its the Trusted/Management subnet, then your config is incorrect.
Clearly you have set the BLUE VLAN to be your Trusted/Management VLAN by the config settings.
I state this because you will confuse the shit out of people following pcunites thread, where blue is just another data vlan and BASE is the Management Vlan.
For me this is issue #1

Issue#2 - Your /IP service settings.....
Your winbox setting for allowed IPs,
a. is nobodys business but your own
b. is set to an ip that makes little sense to me 192.168.0.0/23 The blue vlan if it its your trusted subnet is 192.168.1.0/24 ???????????
c. Why is www not set to disabled, its NOT a secure method of accessing the router.

Okay after review I see what you are doing, you are stating that the IP address (inbound traffic on your VPN connection is valid for connecting to the router!
However, although winbox and SSH are secure means of accessing the router, WWW is not and should be removed.
I only use winbox from within the LAN, as well as remotely of course after coming in on VPN.
THis also tells me that you dont access the router locally for config purposes at all, otherwise for example, 192.168.5.0/24 would also be on the winbox and ssh list!! (if base=management vlan).

Understanding Config#3
The sourcenat rule you have is that to give everyone from the blue subnet going out the ipsec tunnel,, the IP address of the tunnel for source??

Issue#3
Your dst-nat rule is not configured properly.......
add action=dst-nat chain=dstnat missing in-interface or dst address??
comment= "Port forward openVPN port to Zentyal" dst-port=1196 protocol=udp \
to-addresses=192.168.1.1 to-ports=1196

Issue#4
Since by the other two DST NAT rule it would appear you have a fixed static IP address???
But your ISP is pppoe which is usually a dynamic IP address.
SO your config is confusing to the reader!!!!

Issue#5
Your firewall rules, are crap.
First they are disorganized and should be viewed as a contiguous input chain and the forward chain or vice versa not mixed up.
If you insist on using Bogons just route them out, vice firewall rules.
The rest should consist of the default rules modified for your needs PLUS any other rules required to ALLOW TRAFFIC needed.

(-1-) This rule in the forward chain, what is its purpose, it seems to be the same as the incomplete dst-nat rule noted above............?? and probably should be removed.
add action=accept chain=forward comment="forward openVPN to Zentyal" \
dst-address=192.168.1.1 dst-port=1196 in-interface=pppoe-out1 protocol=\
udp

(-2-) These two rules were at the top of the forward chain in order so I moved them down to below the default rules but then I looked more closely at them
and they didnt make sense. if the destination address is 192.168.1.0/24 how can the source address be 192.168.1./0/24 ??? So I removed both!!!
add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \
dst-address=192.168.1.0/24 in-interface=all-ppp src-address=\
192.168.1.0/24
add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \
dst-address=192.168.1.0/24 out-interface=all-ppp src-address=\
192.168.1.0/24

(-3-) All the other rules are youtube garbage.

Fixed.....
As far as bogons.... you could do this if they are actually causing a problem.........

Hi @anav
thank you for your comments. Unfortunately, my knowledge of English is a bit difficult, so I have to carefully study your comments in order to do everything right. Thanks. Until then, some details.

Clearly you have set the BLUE VLAN to be your Trusted/Management VLAN by the config settings.

I set the BLUE VLAN to be trusted to manage the router. This is different from what is described by @pcunite, but I have to manage the router from the local network because ethernet or WiFi is not suitable due to the choice of location. As I wrote in the text, BLE_VLAN is the local network, GREE_VLAN is the DMZ for the server and BASE_VLAN is the guest WiFi (BASE because it is a basic service without anything else). What do you suggest I use a different name for?

Your winbox setting for allowed IPs,

I forgot to disable it, it was off before, I don't use it either... I allow access from the 192.168.0.0/23 subnet because the 192.168.0.0/24 and 192.168.1.0/24 subnets are connected with an IPSec VPN and I need to access the routers of both networks from both subnets...

The sourcenat rule you have is that to give everyone from the blue subnet going out the ipsec tunnel,, the IP address of the tunnel for source??

Excuse me, are you asking or stating that? Could you explain because I don't know what you mean. My English is not the best...

Your dst-nat rule is not configured properly....

Indeed, the IP address was lost, but fortunately it still works, otherwise my wife would have already complained...

Since by the other two DST NAT rule it would appear you have a fixed static IP address???

This is how the service provider provides a static IP address via pppoe service, this is how it should be set. I think that one of the IP addresses of a DHCP range is statically assigned to the pppoe connection and thus remains permanent.

Your firewall rules, are crap.

I need to carefully review the firewall rules as you described. My apologies, according to your previous comments, I modified the previous order, but I do not rule out that I overlooked something.
The bogon list solution is described in the mikrotik wiki as I set it up.

add action=accept chain=forward comment="forward openVPN to Zentyal" \

If I don't set this here, even if the NAT rule is in place, the remote client cannot connect to the server via an openVPN connection because the openVPN server runs on Zentyal... Do you have a better idea?

add action=accept chain=forward comment="Forward l2tp/ipsec remote client" \

If I do not set this here, the remote L2TP/IPSec client cannot connect to the local network (BLUE_VLAN) even if the NAT rule is in place. Do you have a better idea?

(-3-) All the other rules are youtube garbage.

I am happy to learn from others and I know that I do not know everything. Unfortunately, I don't understand why you wrote the quoted text, since these rules are listed in a similar form on the official mikrotik pages and on the iptables pages as examples.
The ssh black list and the port scanner list are very useful for me, because I can see from the lists that routers are constantly being hacked. The bans based on the list visibly reduce the load and sometimes they even give up on the attempt.

I would be happy if you could write why you consider which rule is unnecessary or wrong.

Tomorrow I will thoroughly compare the proposed rules with the ones I have set up and I will apply. Until then, thank you very much for your help and suggestions.

Thanks and Regards

One more thing before I go to sleep because it's past midnight and I woke up at dawn.

If I connect to the router over the Internet with L2TP/IPSec I can't access the Internet, only the local network (BLUE_VLAN). This was not a problem before... What could be the reason for this?

Another problem is that from the BLUE_VLAN the router can be reached from all IP addresses, e.g. From addresses 192.168.1.254, 10.0.20.254 and 192.168.5.254. Why is this and can it cause problems or can it be disabled?

Good night.

Hi @anav,
I took out my old Mikrotik notes and study materials to refresh what I learned about firewall rules. I found that I prepared the forward rules well, but not elegantly or, let's say, efficiently.

In the case of port forward, the problem is caused by adding a "drop all forward" rule at the end of the firewall filters. In this case, the forward rules defined under NAT do not work. The solution to this is to add the forward filter corresponding to prot redirection to each port one by one in the filter rules. Then the port forward defined under NAT will work.
The other solution is to supplement the "drop all forward" rule so that only those that are not dst-nat are dropped ("drop all forward not dst-nat"). In this case, you do not need to set the forward for the filter rules, because the port forward set for NAT works.

The solution you proposed by accepting dst-nat-olt forward for the filter rules is much more elegant than this, because then you don't have to configure all forwards individually, for the filter rules this one entry ("Allow port forwarding") and "drop all forward" is enough. to the end of the filter rules.

Thank you for your suggestion, so the setup is shorter and more efficient and in this case the "Forward l2tp/ipsec remote client" firewall filter rules and other and neither do the other port forwarding rules.

Unfortunately, I did not find a solution to the two problems I wrote earlier, if you have an idea, please write it. These:

If I connect to the router over the Internet with L2TP/IPSec I can't access the Internet, only the local network (BLUE_VLAN). This was not a problem before... What could be the reason for this?

Another problem is that from the BLUE_VLAN the router can be reached from all IP addresses, e.g. From addresses 192.168.1.254, 10.0.20.254 and 192.168.5.254. Why is this and can it cause problems or can it be disabled?

Thanks and Regards

(1) I dont get what you are doing with this line?
/ppp profile
add bridge=BR1 dns-server=192.168.1.254 local-address=BLUE_POOL name=\
l2tp-bridge remote-address=BLUE_POOL

Does this tell me that you have attached this vlan to LT2P tunnel? Is this do direct all blue vlan traffic origination on the router to go out the L2TP tunnel and if so to where??

(2) Yes, change base to GuestWifi or something accurate and wont confuse others......

(3) So if 192.168.1.0 is blue vlan but is really a subnet that needs to be l2tp tunnelled. What the heck is 192.168.0.0/24. Is that remote traffic coming in over the same tunnel??

(4) Assuming thats the case then.......
To allow ipsec incoming traffic to access the local internet you need a forward chain rule.....
This one covers the local interfaces.
add action=accept chain=forward comment="VLAN Internet Access only" \
in-interface-list=VLAN out-interface-list=WAN

so simply add another rule.
add action=accept chain=forward comment="allow ipsec to internet"
src-address=192.168.0.0/24 out-interface-list=WAN


(5) I do not understand what you are saying here.......
Another problem is that from the BLUE_VLAN the router can be reached from all IP addresses, e.g. From addresses 192.168.1.254, 10.0.20.254 and 192.168.5.254. Why is this and can it cause problems or can it be disabled?

Because you have everything in vlans, at L2 you have separation.
In firewall rules L3, you have a drop rule at the end so there should be no vlan to vlan access.
You can always ping the interfaces on the router but actually accessing a device wont happen.

Leaving the first rule out of the NAT part of the config so that it can be understood as to what you are trying to accomplish.
If 192.168.1.1 is a blue subnet that is going out the tunnel L2TP and 192.168.0.0 is remote traffic coming in the tunnel.
Then this rule makes no sense......
add action=accept chain=srcnat dst-address=192.168.0.0/24 src-address=\
192.168.1.0/24

Now that we know you have a fixed WANIP address..........
ip firewall nat
add action=src-nat chain=srcnat to-addresses=fixedWANIP out-interface=pppoe1-out \
ipsec-policy=out,none

add action=dst-nat chain=dstnat dst-address=fixedWANIP \
comment="Port forward openVPN port to Zentyal" dst-port=1196 protocol=udp \
to-addresses=192.168.1.1 to-ports=1196

NOt sure what your 156.53 is alluding to? Is this your fixed WANIP or something else????
add action=dst-nat chain=dstnat dst-address=XXX.XXX.156.53 dst-port=443 \
protocol=tcp to-addresses=192.168.1.1 to-ports=443
add action=dst-nat chain=dstnat dst-address=XXX.XXX.156.53 dst-port=80 \
protocol=tcp to-addresses=192.168.1.1 to-ports=80

Let's clarify. I wrote earlier that there are two subnets. One at the office and the other at home. Both are connected to the Internet with a Mikrotik Hapac2 router. The two locations are approx. They are 15-20 km apart. There is an IPSec VPN between the two routers via the Internet, which connects the office 192.168.0.0/24 and the home 192.168.1.0/24 subnets. This means that the home BLEU_VLAN must be connected to the office network. In this way, all the resources of both subnets are available from both networks.

Regardless, there is an L2TP/IPSec VPN in the router for remote access to devices on the home and office subnets for admin purposes. Through this, I can intervene remotely if there is a problem with routers, servers, IPPBX, etc. It connects to the VPN via a ppp connection and is connected to the BLUE_VLAN because via it IPSec Site2site can also reach the devices on the office subnet with IPSec VPN. That's why the /ppp profile points to the BLU_VLAN DHCP pool, so it gets an IP address from it. This works and I have been using this solution for years without VLAN. Maybe it should be done differently? I am open to any solution...

Finally, there is a third VPN for working remotely on the server. For this, the server runs an openVPN server, and the router's firewall only needs to redirect the openVPN port to the server in the GREEN_VLAN. The advantage of this is that remote connections only have access to the authorized resources of the server and nothing else.

So. (1) The remote L2TP/IPSec user need to connect to BLUE_VLAN this is what the setting is for.

(2) OK, I'll change it.

(3) Please read the explanation above about VPNs.

(4) Do you mean to let BLUE_VLAN through L2TP/IPSec to the WAN? Would this be the counterpart of /ppp profile BLUE_VLAN traffic?

(5) Even though the last line under the firewall filter is "drop all forward", I can still connect from the BLUE_VLAN (192.168.1.0/24) to the router on all its IP addresses (192.168.1.254, 192.168.5.254 or 10.0.20.254). I can not only ping, but I can also connect to the router with Winbox or from a browser.

Leaving the first rule out of the NAT part of the config so that it can be understood as to what you are trying to accomplish.

This is not part of the L2TP/IPSec VPN, but of the Site2site IPSec VPN, so I can't skip it because then the VPN between the office and home doesn't work.

Now that we know you have a fixed WANIP address..........
ip firewall nat
add action=src-nat chain=srcnat to-addresses=fixedWANIPout-interface=pppoe1-out \
ipsec-policy=out,none

I have this as an action=masquerade entry under /ip firewall nat.. Should I change it? But then there will be no access to the Internet...

add action=dst-nat chain=dstnat dst-address=fixedWANIP \
comment="Port forward openVPN port to Zentyal" dst-port=1196 protocol=udp \
to-addresses=192.168.1.1 to-ports=1196

You have already mentioned this to me and I have already modified it.

NOt sure what your 156.53 is alluding to? Is this your fixed WANIP or something else????

These are really public static IP addresses. I marked the first two octets with Xs, leaving the last two to help interpretation.

Okay, talking about the requirements and facts.

FACTS TO CONFIRM:
A. Office Router hapac2 - publicly accessible WANIP? If yes, static or dynamic and type of connection (cable, pppoe etc.)??
B. Home Router hapac2 - Has accessible STATIC WANIP via pppoe connection.
C. Office router has lan subnet 192.168.0.0/24
D. Home router has three subnets 192.168.1.0/24 (blue and trusted - vlan10), 10.0.20.0/24 (Green/dmz-vlan20), and 192.168.5.0/24 (GuestWifi-vlan99)

+++++++++++++++++++++++++++++++++++

REQUIREMENTS:

1. Users on Blue subnet at home must be able to access Office subnet devices.
2. Users on the Office subnet must be able to access Blue subnet devices
3. Admin access from office router, required to Home Router for config purposes, and to Home Router subnets for Troubleshooting.
4. Admin access from Home Router required to Office Router for config purposes, and to Office Router subnets for Troubleshooting.
5. Within the home router the admin must be able to config the router and access subnets
6. Within the office router the admin must be able to config the router and access subnets
7. Admin access from remote locations to Home Router for config purposes and to troubleshoot subnets
8. Admin access from remote locations to Offfice Router for config purposes and to troubleshoot subnets

Note: Requirements 1,2 describe a remote VPN capability for users to do work, and to be able to go from local router to remote router
Note: Requirements 3,4 describe a remote VPN capability for the admin to do work, and be able to go from local router to remote router
Note: Requirements 5,6 describe the need for the admin at the local router to do admin work.
Note: Requirements 7,8 describe the need for the admin to be able to reach either router from a remote location (laptop, smartphone at coffee shop or hotel etc........)

If this indeed captures the requirements, I would use ONE VPN to accomplish all and simplify life.

Hi,
unfortunately, the router is still not accessible via L2TP/IPSec VPN when connecting remotely or via Site2site IPSec VPN from the office.
Could you help me, what could be the problem?

Yeah change 3 different vpns to one vpn (wireguard).
See if disabling the drop all rules at the end (very temporarily) in the forward chain allows connectivity, and if not then try with the input chain very temporarily and if not try both at the same time, again very temporarily.
That should eliminate firewall rules being the problem.

Hi @anav,
I didn't think about that... After disabling the drop input rule, I can access the router with Winbox.

Although there is no internet access when I connect to the L2TP/IPSec VPN.

Unfortunately, I need all three VPNs because they all have different purposes.

How can I fix this?

For the first item, figure out what specific input chain rule you need to allow winbox (from lan resource, from vpn resource etc..) and then put drop rule back in.
You dont want the winbox wide open..........

As for the other, try to re-insert any associated rules you disabled one by one, etc........
There are also methods of tracing traffic flow on the router, to see how far a request in a direction travels and if there is a response but I am not to savvy at that skillset.

I got to the point where if I add the /ip firewall filter action=drop chain=input rule with the In Interface List=WAN setting, the router can be accessed with Winbox via L2TP/IPSec VPN.

/ip firewall filter action=drop chain=input i-interface-list=WAN

Good question, but what could be the reason for this?

If I read that correctly it means that WAN connections to your winbox are correctly blocked but other internal connections such as ipsec vpn incoming traffic that comes out on the router is allowed to winbox, similar how a LAN user may access winbox if the firewall rules permit.

I think this is only partly true. This is how the router can be accessed with Winbox via the L2TP/IPSec remote connection.
But if I connect remotely to the router with L2TP/IPSec VPN, I still can't access the internet, only the local (BLUE_VLAN) network...
The Winbox access is limited to the 192.168.0.0/23 IP address range (192.168.0.1-192.168.1.254) so that it can be accessed from both the office and home networks.

However, from the office via the IPSec Site2site VPN, the router is still not reachable with Winbox, but I can ping the router.

In the end I was basically successful, everything seems to be working. Of course, we still need to test it for a while...

Emboldened by this, today I prepared the configuration of the office router and uploaded it to the router. Everything seems to work here too except for the IPSec Site2Site VPN between the office and my home. Both places have Mikrotik Hapac2 routers and they try to connect with the previously working IPSec settings, but there is an error message "phase 1 negotiation failed due to time up" in the log.

I found that there might be a tcp mss problem, but I checked the set value and it is fine. This would be very important to me because I cannot supervise the office network and devices.

Can anyone help what is causing the problem?

Thanks for your help.

When you are ready to drop 3 different VPNs and use only one let me know? Will need the requirements answered though.

I found a post to restart the routers on both sides at the same time. I tried to restart it from the office earlier, but due to limited access, I could only restart one at a time. Of course, I didn't know any of them because they were working on it with openVPN...

Tonight I restarted both and IPSec Site2Site VPN, L2TP/IPSec remote management VPN and openVPN to the server are working. All three run...

But there is another problem that I can access the office and home networks and the devices operating on them via the IPSec Site2site VPN, but only the remote router is not accessible with Winbox but I can ping it . So I don't even get SNMP data from the remote router...

I need to find the rule that prohibits access to the remote pouter.

Any ideas?

I found a post to restart the routers on both sides at the same time. I tried to restart it from the office earlier, but due to limited access, I could only restart one at a time. Of course, I didn't know any of them because they were working on it with openVPN...

Tonight I restarted both and IPSec Site2Site VPN, L2TP/IPSec remote management VPN and openVPN to the server are working. All three run...

But there is another problem that I can access the office and home networks and the devices operating on them via the IPSec Site2site VPN, but only the remote router is not accessible with Winbox but I can ping it . So I don't even get SNMP data from the remote router...

I need to find the rule that prohibits access to the remote pouter.

Any ideas?

Typically a rule on the remote router is required to allow traffic from outside it, or you dont have a route on a local router to it, OR you dont have route on the remote router to tell it where to send the return traffic from your queries.

Exactly. I got this far because the problem was not solved by disabling the drop rules. I'm trying to figure out what rule would be needed, although I have no idea yet...
I hope that if I figure it out, it will also solve the SNMP problem...

I'm trying all possible solutions in a row and I'm going through the old config to see if it helps.

But it would be a great idea...

So its more likely a routing issue somewhere, or a firewall rule that you have that is already dropping the traffic.

It seems that VLANs are the cause of the problem, but I don't know how to solve it.

There are two Mikrotik routers and both connect to the Internet with static public IP addresses. Between them is an IPSec Saite2Site VPN. This connects the VLAN of one router with the IP address range 192.168.0.0/24 to the VLAN of the other IP address range 192.168.1.0/24. One router's IP address is 192.168.0.254, while the other's is 192.168.1.254.
The traffic between the two VLANs works, all devices are accessible in either VLAN, but the routers cannot be reached from the other VLAN via the IPSec VPN. You can ping the routers from the other VLAN, but you cannot connect to them from the other VLAN with Winbox. The router in that VLAN can be reached from the same VLAN.

It seems that the problem is caused by the VLAN setting. What could be the reason for this?

No one has any ideas?

Thanks and Regards

Quick look at config, posted in #7 above, shows that there isn't a rule allowing winbox access via IP from remote site. Or I didn't find it.

Thanks for your help @mkx.

What rule is needed for this? Can you give me an example?

Thanks and Regards

Once a remote user comes through a vpn and hits the local router, you need an input rule to allow access to winbox.
Same as you would for the admin who resides on the local router.
add chain=input action=accept in-interface=WGNAME src-address=remoteuserIP { If it was wireguard the remote user was coming in on }

This was the solution. I thought that it should be forwarded between the local and the remote subnet. I didn't think that the input caused a problem because it seemed that the traffic was accepted between the two subnets.

I was wrong about this and thank you for pointing out my wrong thinking. That's why sometimes you need a fresh set of eyes to see the problem...

I will test everything again, thanks for the help.

Thanks and Regards