We have a very slow upload speed on our xDSL line and cannot get any faster option except 4G LTE, which has good upload speeds.
Is it possible to setup the mikrotik router to route all download to the xDSL line and all upload to the 4G LTE line?
And how to do it if possible, i found an article about it in the wiki but didtn manage to make it work:
https://wiki.mikrotik.com/wiki/Upload_w ... ad_another

In short: it's not possible.

Different WAN lines come with different WAN IP addresses. Your router has to NAT internal hosts into WAN IP and it should use the correct one for the line it uses for sending the packet out. The WAN host then replies to the same IP address meaning uplink and downlink will use the same line.
If your router chose to NAT internal host to WAN IP address bound to DSL (to "force" WAN host to reply via DSL line) for packet later sent out via 4G, it would very likely get dropped by MNO ... because packet with src-address from some other network has no place to be in MNOs network ... IP address spoofing attacks are using the same technique and every decent ISP (MNOs included) should be fighting against such attacks.

If both lines were terminated at the same ISP, then what you wish for might even work (because "wrongly" NATed packet would be "almost" legal in ISP's network).

@imaljko4, if the poor ADSL performance is due to a technical limitation, not a budget one, you can spawn a virtualized Mikrotik at some server hosting service, build VPN tunnels to it via both your uplinks, and route the download direction from there to your premises via the ADSL line and the upload direction via the LTE line.

@mkx, you wouldn't believe how many ISPs don't check the source IP address of packets you send via them if you get a public IP from them. In most cases what actually prevents source address spoofing from working is the NAT at the ISP's core network.

Thank you for your replies.
We would like to try both scenarios and see if it works(might be that my provider is allowing source address spoofing).
We also have another very fast line in another city, so i could try to setup 2x vpn tunels (xDSl and LTE tunnel) and use that fast line over the vpn tunnels.
Can you just still give me an example, what code should i input to tell the mikrotik router to distinguish between upload and download?
Do i need to first mark the packets and then setup routes, or do i do it with src-nat?
1. So how to setup rules so that mikrotik router knows what is upload and what download and route them accordingly?
2. P.s. If i am using the 2x VPN tunnels, will the hotspot feature still work on my mk Router where i use xDSL+ LTE lines?

Thank you for help

Can you just still give me an example, what code should i input to tell the mikrotik router to distinguish between upload and download?
Do i need to first mark the packets and then setup routes, or do i do it with src-nat?
1. So how to setup rules so that mikrotik router knows what is upload and what download and route them accordingly?

The terms "upload" and "download" are only valid from a perspective of the particular router. So that particular router distinguishes between them very easily:

• download packets come in via one of the WANs and the local router cannot directly influence which one it will be, but it can route them out the appropriate LAN interface
• upload packets come in via one of the LANs, and the local router chooses the WAN for them

.
In the system perspective, you have the router at the site with poor ADSL upload, let's call it the VPN client for simplicity, and the router with good connectivity and public IP address somewhere else - let's call it the VPN server. There are two VPN tunnels established between the two, one via the ADSL (the ADSL tunnel) and another one via LTE (the LTE tunnel). If we keep naming the "download" and "upload" packets from the perspective of the VPN client, their handling is the following:

• the "upload" packets arrive to VPN client's LAN port, and the VPN client routes them to the VPN server; to fulfil the goal of the exercise, its highest priority default route must indicate the LTE tunnel interface as a gateway, and the default route with the ADSL tunnel as gateway must be the backup choice (higher value of the distance parameter, making the route become active only if all routes with exactly the same dst-address but lower values of distance are down). There is no src-nat or masquerade handling on these tunnel interfaces, so the source addresses of the "upload" packets remain unchanged as they arrive to the VPN server. And the VPN server treats them as if they were coming from its own LAN side, i.e. sends them out the WAN and applies src-nat treatment to them using connection tracking.
• the "download" packets arrive to VPN server's WAN port, and thanks to the firewall's connection tracker, they either get "un-src-nated" if they belong to connections initiated from VPN client's LAN side, or possibly they get dst-nated if you need clients in the internet to contact a server at the VPN client site and have configured corresponding rules for that; in any case, the destination addresses of the download packets change from the VPN server's WAN IP to an address from one of the VPN clients' LAN subnets. And the VPN server has routes with all VPN clients' LAN subnets as destinations, the primary ones have the ADSL tunnel interface as gateway and the backup ones have the LTE interface as gateway

.
That's it for the "upload" and "download". A pleasant side effect is that if you add the backup routes in both directions, connections won't break if one of the links (ADSL or LTE) goes down because the NAT treatment is done at the VPN server so the remote server won't notice which tunnel a particlular packet took from the VPN client to the VPN server.


What is much more of a challenge is how to make the outgoing transport packets of the tunnels choose the right WAN (ADSL or LTE). Even if we leave aside the backup functionality and assume you actually intend to use only one direction of each tunnel, to establish them, a bi-directional communicaton is still necessary. There are no sane means to bind a particular tunnel to a particular WAN interface if you use L2TP or PPTP, so you have to use GRE or IPIP tunnels for which it is possible to choose a particular local IP address to use. But unlike L2TP, these tunnelling protocols cannot handle NAT on their own, so you have to use the NAT traversing capabilites of IPsec for this. Given that at least the LTE address is most likely not a public one and the public address to which it is NATed is changing from time to time, the VPN client must act as IPsec initiator.

So all in all you need policy routing to force each tunnel's transport packets via its respective WAN interface, and the primary and backup default routes for the traffic forwarded from LAN to WAN and vice versa going via the tunnels.

The optimal solution depends on:

• what type of LTE modem you have:
  • USB or internal LTE modem of the first type, which is handled as a serial modem with PPP - for this type, there is no dynamically generated DHCP client in /ip dhcp-client print
  • USB or internal LTE modem of the second type, which is handled as an Ethernet interface with a dynamically added DHCP client which lacks the capability to trigger a script,
  • an external LTE modem connected using Ethernet, for which the same possibilities like for the ADSL uplink below apply
• what type of connection you use on the ADSL uplink:
  • PPPoE
  • static IP or DHCP which assigns always the same IP address of a gateway (it doesn't matter whether your own IP changes or not)
  • DHCP which may assign different gateway addresses

So you either have to find the proper setup yourself, or describe your situation using the list above.

2. P.s. If i am using the 2x VPN tunnels, will the hotspot feature still work on my mk Router where i use xDSL+ LTE lines?

I don't see how the hotspot feature should interwork with WAN, so it should keep working.

(...)
In the system perspective, you have the router at the site with poor ADSL upload, let's call it the VPN client for simplicity, and the router with good connectivity and public IP address somewhere else - let's call it the VPN server. There are two VPN tunnels established between the two, one via the ADSL (the ADSL tunnel) and another one via LTE (the LTE tunnel).
(...)

I did something similar for different reasons when I was working some time at Addis Abeba, where I had

• a nice Hotel wifi that got all connections broken by the time it took the generators to kick in after frequent power outages, as the wifi router and DSL modem didn't have UPS,
• a very expensive but "fast" 4G connection using an android phone + USB

This was accessed by a linux server with a UPS and "Shared connection" AP, and I had typically my laptop (with batteries) as client.

What I did was:

• Set up a UDP OpenVPN server in a AWS VM
• Configure it to ignore source address (there is some option for this)
• Set up policy routing in the linux server, with 1% of traffic going though 4G and 99% going through xDSL. No need for routing marks or mangling because all traffic was through the tunnel and tunnel UDP traffic was not sensitive to source

The behaviour was:

• "normal" behaviour 99% of traffic was coming through DSL
• when power outage happened, it started sending traffic fast through 4G and linux/cloud servers re-sent lost packets through it
• when generators kicked in and modem/AP rebooted, 99% of traffic was back into DSL

It worked amazingly well. Here it is a bit different, as UDP OpenVPN is not usable and we would have to send server traffic to the DSL address, but the concept should work well.

@sindy, thank you very much for your detailed help. I am still very busy this days, but once i find some time i will try to set it up like described.
Although might be that this setup will be to advanced for my "basic-beginner" knowledge but i can try.
My setup is as follows:
1. LTE: i use mikrotik SXT LTE device, with integrated modem(not sure which one it is from the list above, but i dont see any dhcp client on it).
2. ADSL- i use rb2011UAS with PPPoE connection.
Thank you

Although might be that this setup will be to advanced for my "basic-beginner" knowledge but i can try.

Easy tasks don't move us forward

1. LTE: i use mikrotik SXT LTE device, with integrated modem(not sure which one it is from the list above, but i dont see any dhcp client on it).

In your particular case, it is not so important that you have the PPP-based LTE modem, I'll explain why.

The questionnaire was there to find out which of the two uplinks possibly has a changing gateway IP address, because we need three categories of routes on the WAN side - one for transport packets of each of the two tunnels and for the actual traffic which uses the tunnels as gateways. And if the gateway IPs were changing at both uplinks, it would require scripting to update the gateway of any route except the default one in the default routing table which the DHCP client updates automatically. However, only the manually added DHCP client allows to attach a script triggered at each address renewal (or initial assignment, or rejection), whereas the one added automatically by the LTE subsystem doesn't have such feature, so the script watching for gateway changes must be triggered by a scheduler.

In your case, given that you use a separate Mikrotik device for the LTE connection and that the ADSL uses PPPoE, both gateways are static - in case of PPPoE it is the interface name, and in case of LTE it would be the IP address of the SXT-LTE in the interconnection subnet if it was used as a mere "LTE to Ethernet converter". So no need for route updating scripts at all.

Even better than that, as you have two separate Mikrotik machines, you don't need to use policy routing to bind each VPN tunnel to another WAN, so you can use L2TP which is among the simplest ones for configuration. Plus, as the data running through the tunnels will be those which would have normally gone directly through the internet, at least for the proof of concept stage you don't even need to bother about IPsec - the only reason to use IPsec would be the relative weakness of the encryption of the L2TP authentication as compared to IPsec encryption.

So follow the example on the wiki and create one L2TP user on the remote Mikrotik for each of the two local ones, just don't add any routes into the /ppp profile at any end. Choose the remote-address and local-address in the /ppp profile at the "remote Mikrotik" not to collide with any of the subnets at any of your two sites (four /32 addresses in total). But before enabling the /interface l2tp-client on the client machines,

• add a route with dst-address=ip.of.remote.mikrotik at each machine, with gateway set to the interface name of the pppoe client on the 2011 and of the LTE interface on the SXT-LTE. This will ensure that once you replace the default route by one pointing to the L2TP tunnel, the transport packets of the tunnel will continue using the "almost physical" WAN interface (PPPoE or LTE). Once done, you can set add-default-route in /interface pppoe-client and /interface lte apn settings to no, and manually add a default route at the SXT-LTE via the L2TP tunnel (/ip route add dst-address=0.0.0.0/0 gateway=l2tp-out1), and a default route at the 2011 via the SXT-LTE (/ip route add dst-address=0.0.0.0/0 gateway=ip.of.sxt-lte.on.interconnecting.subnet).
• add the following firewall rule at the 2011:
  /ip firewall nat add chain=srcnat action=src-nat to-addresses=the.l2tp.ip.of.2011 out-interface=the-ethernet-looking-towards-sxt-lte

Now enable the L2TP clients, the above should be sufficient so that all would work.

I recommend you to draw it before you start implementing it, and to check your existing firewall rules for possible collisions.

Once this minimalistic setup satisfies your expectations regarding the concept, you can think about implementing the failovers to make it tolerant against link outages. It will require just a few more routes to add.

ok. Great. Thank you for help.

Kada dobiješ neki rezultat, napiši, molim.

Yes i will post once i will manage to make the setup, but it will not be that soon as i am currently very bussy with my work.