Custom VLANs

steve800 · August 22, 2022, 2:31pm

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: http://forum.mikrotik.com/t/separated-vlans/159824/1
The solution is based on this post: http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

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?

mkx · August 22, 2022, 4:01pm

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.

anav · August 22, 2022, 4:29pm

Duplicate NM

anav · August 22, 2022, 5:08pm

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.

/ip firewall filter
{input chain}
add action=accept chain=input comment="Allow Estab, Related & Untracked" \
    connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMan)" dst-address=127.0.0.1
add action=accept chain=input comment="Allow l2tp/ipsec IKE (500)" dst-port=\
    500 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow l2tp (1701)" dst-port=1701 \
    in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow l2tp/ipsec NAT (4500)" dst-port=\
    4500 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow l2tp/ipsec vpn (ipsec-esp)" \
    in-interface-list=WAN protocol=ipsec-esp
add action=accept chain=input comment="Allow BASE" in-interface-list=BASE
add action=accept chain=input comment="Allow VLAN" dst-port=53 \
    in-interface-list=VLAN protocol=tcp
add action=accept chain=input comment="Allow VLAN" dst-port=53 \
    in-interface-list=VLAN protocol=udp
add action=drop chain=input comment="[color=#0000FF]Drop all else"[/color][/b]
{forward chain}
add action=accept chain=forward comment="Accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="Accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=input comment="Allow Estab, Related & Untracked" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=accept chain=forward comment="VLAN Internet Access only" \
    in-interface-list=VLAN out-interface-list=WAN
add action=accept chain=forward connection-nat-state=dstnat
add action=drop chain=forward comment="Drop all else"

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??

steve800 · August 22, 2022, 7:34pm

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}”

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.

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.

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.

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

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

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

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?

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…

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

steve800 · August 23, 2022, 9:51pm

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.

steve800 · August 26, 2022, 1:59pm

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: http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
The forum members also helped a lot in this topic: http://forum.mikrotik.com/t/separated-vlans/159824/1

Special thanks to @anav for your the help.

Thanks and Regards
RouterSwitchAP_HAPac2.cfg.rsc (11.1 KB)

anav · August 26, 2022, 4:42pm

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…

/ip firewall filter
{Input chain}
add action=accept chain=input comment="Allow Estab, Related & Untracked" \
    connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMan)" dst-address=127.0.0.1
add action=accept chain=input comment="Allow l2tp/ipsec IKE (500)" dst-port=\
    500 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow l2tp (1701)" dst-port=1701 \
    in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow l2tp/ipsec NAT (4500)" dst-port=\
    4500 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow l2tp/ipsec vpn (ipsec-esp)" \
    in-interface-list=WAN protocol=ipsec-esp
add action=accept chain=input comment="Allow BLUE" in-interface-list=BLUE
add action=accept chain=input comment="Allow VLAN" dst-port=53 \
    in-interface-list=VLAN protocol=tcp
add action=accept chain=input comment="Allow VLAN" dst-port=53 \
    in-interface-list=VLAN protocol=udp
add action=drop chain=input comment=Drop
{forward chain}
add action=accept chain=forward comment="Accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="Accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment="Allow Estab, Related & Untracked" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=accept chain=forward comment="VLAN Internet Access only" \
    in-interface-list=VLAN out-interface-list=WAN
add action=accept chain=forward comment="Allow port forwarding"\
    connection-nat-state=dstnat
add action=drop chain=forward comment="Drop all other forward"

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

/ip route
add  blackhole disabled=no dst-address=0.0.0.0/8 
add  blackhole disabled=no dst-address=172.16.0.0/12 
add  blackhole disabled=no dst-address=192.0.2.0/24
add  blackhole disabled=no dst-address=192.88.99.0/24
add  blackhole disabled=no dst-address=192.18.0.0/15
add  blackhole disabled=no dst-address=192.51.100.0/24
add  blackhole disabled=no dst-address=203.0.113.0/24
add  blackhole disabled=no dst-address=203.0.113.0/24
etc....

steve800 · August 26, 2022, 9:56pm

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.

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?

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…

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…

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

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.

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.

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?

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?

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

steve800 · August 26, 2022, 10:21pm

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.

steve800 · August 27, 2022, 1:46pm

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:

Thanks and Regards

anav · August 27, 2022, 4:04pm

(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.

anav · August 27, 2022, 4:21pm

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

steve800 · August 27, 2022, 6:24pm

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.

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.

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…

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

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

anav · August 28, 2022, 1:46pm

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:

Users on Blue subnet at home must be able to access Office subnet devices.
Users on the Office subnet must be able to access Blue subnet devices
Admin access from office router, required to Home Router for config purposes, and to Home Router subnets for Troubleshooting.
Admin access from Home Router required to Office Router for config purposes, and to Office Router subnets for Troubleshooting.
Within the home router the admin must be able to config the router and access subnets
Within the office router the admin must be able to config the router and access subnets
Admin access from remote locations to Home Router for config purposes and to troubleshoot subnets
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.

steve800 · August 28, 2022, 2:25pm

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?

anav · August 28, 2022, 2:29pm

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.

steve800 · August 28, 2022, 3:24pm

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?

anav · August 28, 2022, 3:45pm

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.

steve800 · August 28, 2022, 4:58pm

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?