As @CZFan has said already: if so, don't bother about PCC, as PCC is here first for load distribution, and only as a side effect it provides some kind of failover. Leaving out PCC will relieve you from having to understand the mangle rules for the moment....the dual WAN support. I need it only as a fail-over without load balance.
Which is also the weakest point of that configuration. Even though the handover interface of WAN1 is Ethernet, there may still be something between your Ethernet port and the actual Internet which may fail without your Ethernet interface going down, and in such case the route via that interface will stay up so no failover will happen. So here I recommend this article explaining how to monitor that accesss to internet is really possible via each WAN. The Mikrotik wiki describes the same coniguration but in a much less explanatory way.... the test was done only by disconnecting the WAN ports.
I agree it would be great - but a great waste of developers' efforts that could be better spent on features which cannot be achieved by configuration. Every user has a different environment, so WAN1 may be anything out of (PPPoE, static IP configuration, DHCP) on anything out of (ethernet, wireless), leaving aside LTE with its two modes (serial or Ethernet emulation) and so can be the WAN2, and every user has different requirements, e.g. a mere failover in your case and load distribution in someone else's case. Others may want one of those basic approaches for most of the traffic but some services to be accessed solely via one of the WANs. So I personally like the current approach where QuickSet is for people who have bought Mikrotik by chance and the real configuration interface is for those who have chosen it for its flexibility. Flexibility means a lot of things can be configured, and without an understanding what each setting is necessary for it is close to impossible to answer properly all what a configuration wizard would have to ask.Still it would be great if they've added something as the quick config for dual WAN options as it's a common thing now days. This router would be used for experiments for now until I start to feel a bit more comfortable with the OS and I get my knowledge together.
I though about something like this but if I set the ADSL modem to bridge I'd need the password so I'll be able to create the pppoe from the mikrotik. Sadly I don't have this information and the ISP won't give it to me if requested. Normally I won't even have access to their device and would be forced to manage it by their limited web but however I have access to the modem. I'd probably be able even to recover the password for the pppoe but it may be too much. Other problem that will result directly from that is the DVR which needs some ports forwarding so I'd have to configure it too.PCC is for load balancing, from your description, you do not need that.
Then I would also change the ADSL Modem to bridge mode and configure ADSL PPPoE on the Mikrotik.
The do not use the "Add default Gateway"in the PPPoE settings, instead create static default routes with a distance of 1 and 2, 2 for the adsl and use "check gateway " on the static routes
Thanks for the link, I'm going to check it for sure and I'll try to make this work. According to the quick settings - it is true that it's a bit of a hard work to implement it. Still even if it's a bit tricky to set things up and you'll need a lot of reading and network knowledge I really like this product. You can learn a lot from it.As @CZFan has said already: if so, don't bother about PCC, as PCC is here first for load distribution, and only as a side effect it provides some kind of failover. Leaving out PCC will relieve you from having to understand the mangle rules for the moment.
Which is also the weakest point of that configuration. Even though the handover interface of WAN1 is Ethernet, there may still be something between your Ethernet port and the actual Internet which may fail without your Ethernet interface going down, and in such case the route via that interface will stay up so no failover will happen. So here I recommend this article explaining how to monitor that accesss to internet is really possible via each WAN. The Mikrotik wiki describes the same coniguration but in a much less explanatory way.
Fair enough but it isn't working even with the static address of the second ISP. I mean the 0.0.0.0/0 with GW 8.8.8.8 is still unreachable.First of all, the recursive routing on which the scriptless failover is based does not work if a route's gateway is set to anything else than an IP number anywhere in the recursive chain. So you cannot use the interface name (PPPoE-out) as a gateway for dst-address=8.8.8.8, you have to use the IP address provided by the PPPoE server.
dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1
dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2
dst-address=0.0.0.0/0 type=blackhole distance=9
dst-address=0.0.0.0/0 gateway=the.ip.from.isp distance=10
So what you are saying is thatThe used address is not actually used by anything by default, no packets are sent to it, so it don't matter what you put there.
Ah I was afraid it won't be so straight forword with the PPPoE...When I say "you must use as gateway the IP address provided by the PPPoE server", I have in mind the address which that PPPoE server provides as a gateway, not the one it assigns to you. Is it what you mean by "static address of the second ISP"?
Normally, where you are a PPPoE client, the server assigns you your own address and indicates its own IP address which you may use as a gateway for anything you want to send via that server. But in most cases, you can use the interface name as well; recursive routing on Mikrotik is one of the exceptions where you can't. I have seen you have set add-default-route in /interface pppoe-client to no, but when you do that, you won't learn the gateway address. So you have to set it to yes for a while to learn the address "manually", or keep it on yes and set default-route-distance to e.g. 10 and add a blackhole route with a lower distance, so the final set of default routes would be
Then, you would use an on-up script from a /ppp profile attached to the /interface pppoe-client to copy the gateway IP from the route with distance=10 to the route with dst-address=8.8.8.8/32. But it only makes sense to do it this complex way if the PPPoE server doesn't provide the same gateway IP address each time.Code: Select alldst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 dst-address=0.0.0.0/0 type=blackhole distance=9 dst-address=0.0.0.0/0 gateway=the.ip.from.isp distance=10
Where you are a DHCP client, you must use the IP address provided by the DHCP server as a default gateway (or use the routing table provided by the DHCP server as Option 121 but that's out of scope of this).
So when the Line 1 fail and then reconnect it may take a different Remote address so the recurse fails as the gateway in line 3 is different. You have mentioned some kind of a script but isn't there an easier way to always take the current remote address and to put it as the GW without scripting? It's really sad that this isn't working with the pppoe interface. I was able to get the address of the GW from the status bar of the pppoe interface. I wasn't completely able to understand the method proposed by @Sob's./ip route
add check-gateway=ping distance=1 gateway=8.8.8.8
add check-gateway=ping distance=2 gateway=8.8.4.4
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.x.x scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=x.x.x.x scope=10
The pppoe is using 1.1.1.1 and 8.8.8.8 as DNS and for the ADSL I have to check it because currently I'm using the ADSL address as DNS.Whatever IP you use as your target is only reachable via the primary route. If the primary route is down, that IP address will be unreachable. If you use 8.8.8.8 to resolve DNS, the DNS service will be down when the primary route is down. Therefore if you use Google for DNS and use 8.8.8.8 as the routing target, you should use a different Google DNS server such as 8.8.4.4 for DNS instead.
You're mixing together the DHCP case with the PPPoE case.The remote address of the PPPoE is changing. It seems to be either 5 or 12 but it changes.
You have mentioned some kind of a script but isn't there an easier way to always take the current remote address and to put it as the GW without scripting? It's really sad that this isn't working with the pppoe interface. I was able to get the address of the GW from the status bar of the pppoe interface. I wasn't completely able to understand the method proposed by @Sob's.
This is normal - for any destination address the routes with the longest, i.e. most exactly matching, dst-address prefix are chosen. So if at least one route with dst-address=8.8.8.8/32 exists and is active, routes whose dst-address prefixes also match 8.8.8.8 but are shorter (wider), such as 8.8.8.0/24 or 0.0.0.0/0, are never chosen for delivery of packets to 8.8.8.8. This has two consequences:Also I found in an article that the recursive method has the following limitation:Whatever IP you use as your target is only reachable via the primary route. If the primary route is down, that IP address will be unreachable. If you use 8.8.8.8 to resolve DNS, the DNS service will be down when the primary route is down. Therefore if you use Google for DNS and use 8.8.8.8 as the routing target, you should use a different Google DNS server such as 8.8.4.4 for DNS instead.
PPPoE creates a Point-to-Point interface. For all interfaces of this type, there is no actual need to use any address of the remote device because "the remote end of the tunnel" is the only address you need - whatever you send out that interface will end up on the single remote device. This is a difference to Point-to-Multipoint interface where you need an address of a particular device in addition to the name of the interface. For practical reasons, the gateway addresses are configured as IP addresses, which allows to quickly choose the interface by its associated "network" address, and there the IP address of the gateway device is translated into its MAC address.it's not still completely clear for me.
I'll stay polite so I won't translate any of the Czech sayings related to this kind of statements, but it would at least take long to happen (if at all possible because I'm not deep into the recursive next hop search algorithm, so maybe there is some reason which excludes using the interface name as gateway). So if you want it now, use the workaround suggested or use a script. In fact, the next-hop search mechanism was also not originally intended for the failover use. Which BTW also means that the failover may happen up to about 10 seconds after the active WAN path breaks because this is how often the check-gateway pings are sent.If it was possible to use the pppoe interface instead of exact GW it would be way easier...
So I've tried that but sadly while trying to connect it says the connection is terminated and it isn't able to make a connection when I'm using a random remote address.For PPPoE (used at your WAN1), there is a script-less way which @Sob has described: you create a copy of /ppp profile named default, give it a name like my-pppoe-profile, and set the remote-address item in that new profile to some private address which isn't in conflict with any private subnet you use anywhere in your network - say, 10.22.33.44. In /interface pppoe-client configuration, you set the profile item to my-pppoe-profile. And in the individual route(s) to the anchor IP(s) used to monitor PPPoE availability, you use the 10.22.33.44 as a gateway address. This way, the remote-address setting from the /ppp profile my-pppoe-profile overrides the setting which came from the PPPoE server, and so it remains stable even though the PPPoE server sends you a different one each time.
Oops, I didn't test that before. But it's true. RouterOS as PPPoE server doesn't seem to care and I don't see it doing anything with that address. But other implementation surely can.... but the PPPoE client and server discuss the addresses during the startup phase ...
/system script
add name=update-pppoe-route source=":local gtw \$\"remote-address\"\
\n:local rte [/ip route find dst-address~\"8.8.8.8/32\"]\
\n:if ([/ip route get \$rte gateway]!=\$gtw) do={\
\n /ip route set \$rte gateway=\$gtw\
\n}\
\n"
/ppp profile
add name=my-pppoe on-up=update-pppoe-route
/interface pppoe-client set [find name=your-pppoe-client-interface-name] profile=my-pppoe
Oook, this one worked, now it's updating the GW every time in the route. I hoped it would work without scripts and so but at least there is a way. The only thing I changes in the ppp profile was under Change TCP MSS from default to yes as in the default profile it's set to yes.OK, so one possibility would be to use a script to generate a ton of routes for the whole range of remote address values the ISP provides.
A better possibility is to use an on-up parameter of the /ppp profile to call a script to update the lowermost recursive route:
This way, the gateway of the route will be set to the remote address value received from the server each time the pppoe-client interface goes up and the currently configured gateway in that route is different.Code: Select all/system script add name=update-pppoe-route source=":local gtw \$\"remote-address\"\ \n:local rte [/ip route find dst-address~\"8.8.8.8/32\"]\ \n:if ([/ip route get \$rte gateway]!=\$gtw) do={\ \n /ip route set \$rte gateway=\$gtw\ \n}\ \n" /ppp profile add name=my-pppoe on-up=update-pppoe-route /interface pppoe-client set [find name=your-pppoe-client-interface-name] profile=my-pppoe
/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8
add check-gateway=ping distance=2 gateway=8.8.4.4
add distance=1 dst-address=8.8.4.4/32 gateway=192.x.x.x scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=x.x.x.x scope=10
/ppp profile
add change-tcp-mss=yes name=my-pppoe on-up=update-pppoe-route
Not sure why the ports are set to 100Mbts instead of 1Gbps???/interface ethernet
set [ find default-name=ether1 ] name=WAN1-Ether1 speed=100Mbps
set [ find default-name=ether2 ] name=WAN2-Ether2 speed=100Mbps
set [ find default-name=ether3 ] speed=100Mbps
set [ find default-name=ether4 ] speed=100Mbps
set [ find default-name=ether5 ] speed=100Mbps
/interface bridge port
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
I'm still open to an scriptless method if someone have idea./interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=WAN1-Ether1 list=WAN
add interface=WAN2-Ether2 list=WAN
add interface=pppoe-out1 list=WAN
What is the traffic volume through WAN2? Each route with check-gateway=ping generates one ping request and response every 10 seconds, maybe up to three requests when the monitored IP doesn't respond (which is how netwatch behaves so I'd expect the same approach to be reused also here). Another source of traffic is DHCP renewal whose frequency depends on the lease time choice of the server (i.e. your ADSL modem).The only interesting thing is that via WAN2 eth port there are some spikes in the Tx and Rx from time to time so something is passing there, probably it's the connection test?
Me neither, but it is not the default setting. If you use /interface ethernet set [find] speed=1Gbps, the speed will not be limited to 100 Mbit/s any more and the export should stop showing the speed parameter at all as 1Gbps is the default value, which means that the set lines for ether3 to ether5 will disappear from the export completely as they will not contain any non-default setting any more. If you are 120% sure you haven't modified those settings manually (even by mistake), some bug of this or some previously running software version may be responsible.Not sure why the ports are set to 100Mbts instead of 1Gbps???
Just FYI, making WAN1-Ether1 an /interface list member is pointless unless you have an IP configuration attached directly to it. From the perspective of the IP firewall, only the pppoe-out1 is an IP interface and that WAN1-Ether1 is its underlying physical path is irrelevant for the IP firewall.Code: Select all/interface list member ... add comment=defconf interface=WAN1-Ether1 list=WAN
Out of curiosity, why would you like to get rid of scripts completely? Whereas a script directly controlling the failover itself has to be scheduled for a frequent periodical run, the script updating the route is only triggered by address reassignment which should happen rarely, so it causes a negligible CPU load and flash chip wear.I'm still open to an scriptless method if someone have idea.
It's really minor - between 500 and 600 bps more likely around 590. When I put load to it the whole traffic pass through the working WAN i.e. WAN1 where the pppoe is set. Moreover the Dest. 8.8.4.4 through the GW of the ADSL is reachable and only the default route 0.0.0.0/0 is inactive (blue) so I guess that its most likely the ping.What is the traffic volume through WAN2? Each route with check-gateway=ping generates one ping request and response every 10 seconds, maybe up to three requests when the monitored IP doesn't respond (which is how netwatch behaves so I'd expect the same approach to be reused also here). Another source of traffic is DHCP renewal whose frequency depends on the lease time choice of the server (i.e. your ADSL modem).
I haven't touched anything instead of setting the second WAN and removing it from the bridge. The interfaces are with active 10/100/1000 (they all have ticks) but It may be the auto negotiation that is doing it. For sure the ADSL is 10/100 and one of the routers I'm using as AP is also 10/100 (it's now connected to the eth3 port) if I manually set it to 1000 half/full it's shown as 1000 in the export.Me neither, but it is not the default setting. If you use /interface ethernet set [find] speed=1Gbps, the speed will not be limited to 100 Mbit/s any more and the export should stop showing the speed parameter at all as 1Gbps is the default value, which means that the set lines for ether3 to ether5 will disappear from the export completely as they will not contain any non-default setting any more. If you are 120% sure you haven't modified those settings manually (even by mistake), some bug of this or some previously running software version may be responsible.
I know but because I'm stepping on the default settings and the port was listed by default I haven't removed it from there - just added the pppoe-out to the list so the rules can apply.Just FYI, making WAN1-Ether1 an /interface list member is pointless unless you have an IP configuration attached directly to it. From the perspective of the IP firewall, only the pppoe-out1 is an IP interface and that WAN1-Ether1 is its underlying physical path is irrelevant for the IP firewall.
Mainly because it's something that I'm not familliar with. I'd prefer to know everything that I've done to any settings and as the scripting is a bit advanced in this learning process I'd like to stick to the scriptless settings. However I'll check the syntax of the script language and I'll try to decode the script so I'd be able to reproduce it myself. It seems that in the current settings it will work only if the checking address is 8.8.8.8. As I'd want to realize the recursion with two different hosts just to be more reliable if it somehow happen that the google DNS is down. I'm to see how these settings will work with the script.Out of curiosity, why would you like to get rid of scripts completely? Whereas a script directly controlling the failover itself has to be scheduled for a frequent periodical run, the script updating the route is only triggered by address reassignment which should happen rarely, so it causes a negligible CPU load and flash chip wear.
It would be great if it had possitive side for you, because you really helped me a lot. It seems that in this forum the community is really open and eager to help to the new users who are not familiar with the ROS. So thank you very much for the help.But thank you for pushing me to think about flash wear again, I've got an idea how to get rid of configuration updates in another design
Yeah it would be great if the suggested by @Sab workaround was possible but at least we learned that it depends on the server side and it could be problematic. It could be even a problem if initially it works but for some reason the ISP decide to change the settings of its servers.It's a pity that some PPPoE servers are not tolerant to the solution suggested by @Sob, because it means it cannot be used to resolve a conflict situation where the servers of two PPPoE uplinks provide the same remote-address.
The advertise configuration parameter on one hand and the full-duplex and speed configuration parameters on the other one are used in an exclusive-or manner depending on the auto-negotiation setting. So if you have auto-negotiation set to yes, the speed configuration parameter should be ignored and the negotiated speed should be shown.I haven't touched anything instead of setting the second WAN and removing it from the bridge. The interfaces are with active 10/100/1000 (they all have ticks) but It may be the auto negotiation that is doing it. For sure the ADSL is 10/100 and one of the routers I'm using as AP is also 10/100 (it's now connected to the eth3 port) if I manually set it to 1000 half/full it's shown as 1000 in the export.
The scripting works with lists, so you can configure a selection condition in the find which matches several routes so the find returns their list, and then the set will be applied to all items on the list. So you may use regular expressions (dst-address~"1.2.3.4|8.7.6.5") or a logical "or" ((dst-address="1.2.3.4" or dst-address="8.7.6.5")) to make the find return IDs of both the route to 1.2.3.4 and the route to 8.7.6.5.Mainly because it's something that I'm not familliar with. I'd prefer to know everything that I've done to any settings and as the scripting is a bit advanced in this learning process I'd like to stick to the scriptless settings. However I'll check the syntax of the script language and I'll try to decode the script so I'd be able to reproduce it myself. It seems that in the current settings it will work only if the checking address is 8.8.8.8. As I'd want to realize the recursion with two different hosts just to be more reliable if it somehow happen that the google DNS is down. I'm to see how these settings will work with the script.
It did as I've found an issue in that other design. And it has also pushed me to raise a ticket with support because something in RouterOS behaves counter-intuitively, so the idea I've got has failed because it was based on what the intuitive behaviour would be.It would be great if it had possitive side for you
In principle yes - the scripts are bound to /ip dhcp-client in a slightly different manner than to ppp interfaces (directly rather than via a profile, and a single script is invoked at any change so it has to determine the actual invoking event based on a context variable and choose the corresponding behaviour), but the task is the same - at each assignment or renewal of IP configuration, check whether the new gateway IP is the same like the previously assigned one and if it differs, modify the configuration.is the script for the let's say a dynamic IP common to the one you proposed for the pppoe GW monitoring?
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes port=2200
set api disabled=yes
set api-ssl disabled=yes
/ip dns
set servers=1.1.1.1,1.0.0.1
allow-remote-requests=no
/ip address
add address=192.168.x.x/24 interface=bridge network=192.168.x.x
add address=192.168.x.x/24 interface=ether2 network=192.168.x.x
As it turned out the pppoe server wasn't giving the same remote address so the recursive wasn't properly working. Thanks to @sindy who wrote a script I was able to finally set it up. I've added two lines to the script so it could change the remote address not only for one address but for two as the dual WAN with multiple gateway ping check uses 2 for every connection. Here is the script:/ip route
add distance=1 gateway=10.1.1.1
add distance=2 gateway=10.2.2.2
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.x.x scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=x.x.x.x scope=10
add check-gateway=ping distance=1 dst-address=10.1.1.1/32 gateway=8.8.8.8 scope=10
add check-gateway=ping distance=1 dst-address=10.1.1.1/32 gateway=208.67.220.220 scope=10
add check-gateway=ping distance=1 dst-address=10.2.2.2/32 gateway=8.8.4.4 scope=10
add check-gateway=ping distance=1 dst-address=10.2.2.2/32 gateway=208.67.222.222 scope=10
add distance=1 dst-address=208.67.220.220/32 gateway=x.x.x.xscope=10
add distance=1 dst-address=208.67.222.222/32 gateway=y.y.y.yscope=10
:local gtw $"remote-address"
:local rte [/ip route find dst-address~"8.8.8.8/32"]
:local rtf [/ip route find dst-address~"208.67.220.220/32"]
:if ([/ip route get $rte gateway]!=$gtw) do={
/ip route set $rte gateway=$gtw
}
:if ([/ip route get $rtf gateway]!=$gtw) do={
/ip route set $rtf gateway=$gtw
}
Once I manage to deal with this I'd finally set up the VLANs/ip firewall nat
add action=dst-nat chain=dstnat dst-address=my-static-address dst-port=xxxx protocol=udp \
to-addresses=Local-address of the server to-ports=xxxx
/ip firewall filter
add chain=forward dst-port=xxxx protocol=udp dst-address=Local-address of the server in-interface=ether1 action=accept
Sadly It didn't worked even this way. The ports are the same and it's the default 1194Your firewall NAT rule looks okay, if you your destination ports are the same as the to ports, you can drop the to=ports and just have the to-adddresses.
The Filter rule looks wrong, all you need is the following:
add action=accept chain=forward comment=\
"Allow Port Forwarding - DSTNAT" connection-nat-state=dstnat
I'm indeed trying to connect to the server from a machine in the same subnet as the server. It worked with the other router but I'm going to try it from the network of the ADSL. On the server the public address is set to the same address I'm setting the NAT, it's UDP with the standard port and cert/key + password.chain=dstnat action=dst-nat to-addresses=Local-address-of-the-server protocol=udp
dst-address=Public-static-address-of-the-pppoe in-interface=pppoe-out1 dst-port=1194 log=yes
log-prefix=""
No additional firewall ruleschain=dstnat action=dst-nat to-addresses=local-server-address protocol=udp
in-interface=pppoe-out1 dst-port=1194 log=yes log-prefix=""
Yes.There is a rule in the firewall:
defconf: drop all from WAN not DSTNATed - I believe you're talking about this one?
This definitely needs to be addressed unless you only need it for the testing phase. Either give the server its own subnet or use a src-nat rule (/ip firewall nat add chain=srcnat action=src-nat protocol=udp dst-address=the.lan.ip.of.the.server dst-port=1194 to-addresses=the.ip.of.mikrotik.itself.in.the.lan.subnet.I'm indeed trying to connect to the server from a machine in the same subnet as the server.
Slow down here, I've probably misunderstood what you wrote. As far as I remember, you only tell the openvpn server on which local addresses to listen if you don't want it to listen on all of them. So if you specify any address at all, it should be the local LAN one of the server, not the public one which is not up on the server itself.On the server the public address is set to the same address I'm setting the NAT
I agree with the intention, but the thread is somehow quite curly and I wasn't sure I've sourced everything from it. After all the doctors structure their case notes in their own way, whereas here different people with different ways of thinking contribute so finding the bit of information you need right now is a challenge.Sorry for the long period but I thought it would be better to use the same thread as the information would be in one place in case someone else have a similar problem.
The limiting factor here is the check-gateway ping rate which is hardcoded to 10s. You mention 30 seconds needed for a failover, but you get this because additional factors contribute to the total time:what do you think of the current failover configuration? I think that in this scenario would be enough to guarantee maximum reliability It would be great if it was possible to force a faster switch in case of problem with the main link but it's still good.
It depends on the rest of your network topology. If all your end devices are connected directly to Mikrotik, there is no need to deal with 802.1Q as you may create as many bridges as you want and assign the interfaces to these bridges freely. If you want to connect external switches to provide access ports for the end devices, or to connect devices which make use of 802.1Q internally (such as host servers for virtual guests), you save cables and interfaces by use of VLAN tagging (802.1Q, 802.1ad and others).One more side question - what would be better to use port based VLAN or 802.1Q?
It was just for testing but with the additional nat rule it works.This definitely needs to be addressed unless you only need it for the testing phase. Either give the server its own subnet or use a src-nat rule (/ip firewall nat add chain=srcnat action=src-nat protocol=udp dst-address=the.lan.ip.of.the.server dst-port=1194 to-addresses=the.ip.of.mikrotik.itself.in.the.lan.subnet.
Well its a plug-in to the OpenMediaVault server and its port is set to the default OpenVPN, The thing is that if I set the public address to its own local one the VPN server would be accessible only from the local network. The remote address on the server is set to the public static address of my main link so when the clients try to connect to the public address with the needed port it's redirected to the local address of the server. Or at least I think that this is the case. It is possible that my setup has flows but I don't see how it would work without the real public address.Slow down here, I've probably misunderstood what you wrote. As far as I remember, you only tell the openvpn server on which local addresses to listen if you don't want it to listen on all of them. So if you specify any address at all, it should be the local LAN one of the server, not the public one which is not up on the server itself.
It works with the static adress as dest. adress and without it set in the rule, honestly don't know which one should be the right.chain=dstnat action=dst-nat to-addresses= local-server-address protocol=udp dst-port=1194
log=yes log-prefix=""
OK, so the public address is there for clients to connect to, not for the server to bind at. This way it makes sense.Well its a plug-in to the OpenMediaVault server and its port is set to the default OpenVPN, The thing is that if I set the public address to its own local one the VPN server would be accessible only from the local network. The remote address on the server is set to the public static address of my main link so when the clients try to connect to the public address with the needed port it's redirected to the local address of the server. Or at least I think that this is the case. It is possible that my setup has flows but I don't see how it would work without the real public address.
That way (without in-interface or dst-address) it handles any connection to udp 1194, even if you'd e.g. have a client in the LAN trying to connect to some external server. So adding the in-interface (or in-interface-list) to the rule with a proper value will save you future headache.This is the current NAT rule that works for the outside networks:
chain=dstnat action=dst-nat to-addresses= local-server-address protocol=udp dst-port=1194 log=yes log-prefix=""
It works with the static adress as dest. adress and without it set in the rule, honestly don't know which one should be the right.
If everything that belongs to one VLAN is connected to one interface of Mikrotik, albeit via an external switch, and everything what belongs to another VLAN is connected to another interface of Mikrotik, using yet another switch, port-based VLANs on Mikrotik are enough. If the external switches support 802.1Q VLANs, deploying 802.1Q at Mikrotik and those external switches would provide you with more flexibility in physical placement of the connected devices, as you could have ports from both VLANs on both switches.As for the VLAN - currently it's on a different switch which is attached directly to one of the ports of the Tik. Everything on that switch is should be in a different VLAN with internet access/DHCP. The main VLAN is using another smart switch right after the Tik and from there APs.
The fact that ping recovers quickly is a surprise to me as a single ping sequence should suffer from the same factor like the TCP connections - for TCP and UDP, source and destination IP addresses and ports are used to identify a tracked connection, for ping it is source and destination IP addresses and the identifier field of ICMP echo packets. So again, all packets bearing this same identifier value (and IP addresses of course) are matched to the same tracked connection and maintain the src-nat address until this connection times out. Normally, all icmp echo request packets generated by a single run of the "ping" utility have the same value of the identifier field, so the same ping running "forever" should not ever recover, whereas a new one has a different identifier value and thus creates a new tracked connection, which starts when the primary WAN has already been found to fail, so it gets the src-nat address of the backup one.Interesting thing about this failover is that when I'm checking it with constant ping from the command prompt it seems that the second link takes over imminently with a singe request timeout but for the internet to properly work it takes few seconds (between 15-30 on average) I don't know if in this case it isn't from the DNS. When the main link is up again it takes a bit more to switch to it but the ping comes way faster then the "internet"