Greetings to all,
as expected I already used wiki, forums and videos to make my dual VDSL with PPC configuration working and i am more or less satisfied with speed (reason behind all of this was idiotic policy of our ISP to disallow bonding for certain speeds).
Problem is indeed with portforwarding… it is kinda chaotic.
details:
VDSL1~pppoe1~VLAN1(id848)~public static ip~1.1.1.1
VDSL2~pppoe2~VLAN2(id848)~public static ip~2.2.2.2
both VDSLs do have same GW (same ISP)
RDP port through WAN: 5000
bridge ~ LAN ~ DHCP server ~ 192.168.100.0/24
Fundamentally i need to access my home workstation from my workplace through forwarded rdp port. But when i am checking the state of connections in winbox (IP-Firewall-Connections (filter: Reply Src. Address/Port=3389) I can sometimes see in destination address column/field value “1.1.1.1:5000” and connection mark column value “GTW2” (or “2.2.2.2:5000” together with connection mark “GTW1”), this state results in failed TCP handshake, ofc.
Other attemps may work but only when its paired correctly like 1.1.1.1:5000 -connection mark ->GTW1 or 2.2.2.2:5000 - connection mark → GTW2.
On certain different types of connections I have even seen connection mark to be altering between GTW1 and GTW2, for same connection it may change in time. Ups
Problem:
From my understanding when packet goes from one VDSL to my home network, reply packet does not always return through the same VDSL line to internet (incoming GW and outgoing GW are not the same).
Question:
Is following config working as intended and portwarding cannt work ever at all? Or do i have to make some workaround that would included PCC bypass for certain incoming connections?
I am not a mikrotik professional nor networking mastermind. I tried to get training but this human malware is obstructing everything…
Please, any comment is welcome. I am slowly loosing my mind doubting everything what works so far.
(1) Not sure if the routes are okay (unclear to me what the differences in distance on the rule may do or not do)
(2) the dstnat rule is funky
add action=dst-nat chain=dstnat dst-port=5000 protocol=tcp to-addresses=192.168.100.120 to-ports=3389 Is missing the in-interface-list=WAN for example.
(3) Dont think you need to put in source address on the masquerade rules.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
But the main thing to address is requirements.
IS IT really a requirement to go from work to home using both home WANIP connections???
This adds needless complication IMHO.
Without any mangling, any query coming in on VDSL2 (the secondary WANISP for routing) will have returns going out VDSL1 as that is the primary route. So if you enter your workstation via VDSL1, you will never have an issue and you dont need to mangle.
The question for me is why complicate life and add mangling and try to come in on VDSL2??
Especially because there is no redundancy (if one connection goes down they both will as the source is the same).
First of all question is if your LAN and BRIDGE set up as well as IP is all correct.
But what is definitely wrong is the route setup…
What you have is that EVERYTHING goes out to PPPOE1!
Only if PPPOE fails, it goes over to PPPOE2…
So if you go inside from PPOE2 the respons will go out to PPPOE1 as the route for PPPOE2 has higher distance as the
0.0.0.0 route.
If you want to do dual WAN (same WAN IF working with PCC) you would do (for example) :
anav
-in-interface-list has following options : dynamic /none / static ; typo from your side?
-i did add in-interface to each rule, but no change
-masquerade indeed works fine w/o source address
-for work2home connection i dont care about bandwith, i may use one specific VDSL only, thats the reason why i asked about workaround (binding certain traffic to certain WAN only), i dont have any positive experience nor solution for this while load balancing is active
-load balancing is used to get as much bandwith as i can, when i am at home
WeWiNet
-lan/bridge was already checked by our local support (i will post full config later on)
-my previous config was correctly spreading traffic equally with preference of one gateway (route marked as DAC with Pref.Source visible)
-i had updated config based on your route suggestion, this had no effect, no benefit from bandwith nor GTW1/2 misshandling
Interesting observation/explanation of change after 2-3 recent routeros updates:
-current config with current routeros had to be changed a bit in masquerade’s out-interface value, i had to merge both rules into one using “all-ppp”.
Reason behind was that, if one pppoe connection dropped, then its NAT rule went red and mikrotik refused to re-dial connection automatically
I don’t think so with the distance you have had before. You marked traffic equally, but it all went out on PPPOE1.
Only if it failed it went to PPPOE2.
Have you checked the outbound traffic on the out interface if traffic actually hit that one?
You should also remove the first two mangle rules.
The distances In Routes will not cause traffic to only go out pppoe1 as they are connection / routing mark.
agree that those 2 mangle rules is cause of problem and must removed, what is happening is there are no pssthrough set on these, so incoming traffic is accepted and rule processing stops with these and does not get the necessary connection marks
great thanks to WeWiNet ,CZfan, anav
issue with loosing proper marking of the wan’s path is gone, those two rules were indeed the cause of observed annoying issue
one last question:
-how to bind certain traffic (defined by either internal ip+port, or external ip+port ) to certain wan
using this feature, for example:
-i have synology in internal network and its providing me with ddns, now its kinda hopping every three minutes between available wans
(i think that synology uses outgoing traffic stream from internal network through wan with specific port 80ish or 5001ish to reach their ddns service)
idea:
-i was thinking about adding 1 ( i think ddns is initiated by device) mangle rule in front of any other rules to be processed first
, then the rule should indeed work.
You might not want to specify the port if you just consider that this NAS will always use same outgoing WAN
as long as that WAN is up and running (keep in mind, if WAN1 goes down, everything goes over to WAN2 so you are save).
But ok, you can add one (or more) specific port only.
