I would need some advise: I must route certain connections towards different gateways (with mangles and fw address lists)
The tricky part is that I can only make the decision between desired ROUTE1 and ROUTE2, when I actually see the new connection’s dst address.
Even more precisely, I have to do some analysation on the dst address before I can make the decision.
To be very easy, I have solved this with basic firewall lists and a mangle and two scripts:
The mmangle (collector): adds every new connections’ dst address to a firewall address list TOCHECK.
First script (collection start): enables the above mangle.
Second script (evaluator): disables the above mangle, and analyse all addresses on TOCHECK, and either put them in ADDRESSLIST-ROUTE1 or ADDRESSLIST-ROUTE2. (and also removes the item from TOCHECK list)
So after second script finished, TOCHECK is empty, and my two addresslists are containing a growing list of dst addresses which has to be routed either towards ROUTE1 or ROUTE2.
This is working perfectly, but has an obvious drawback: all connections have to be built up two times to be routed correctly.
I wish to have an immediate effect, I.e: analyse the new connection while holding it back (not routing yet), and only proceed once analysation (done by a script) has finished and evaluated the dst address (and put into the correct address list).
Is this something I can achieve or this is too much for the beloved Tik to do?
Actually I haven’t found better solutions: I want to separate Viber application’s traffic from everything else.
But Viber’s algo is closed, so best bet I found can only distinguish based on dst-addr.
One cannot control traffic by application in MT for the most part so dst address is a better choice, OR a much more expensive device with expensive paid services.
at the end of the day without more information such as
/export hide-sensitive file=anynameyouwish its too much of a guessing game.
Not sure how complex this is but it may be a simple as… assuming vers 7 firmware may be done without any mangling…
The reality is the requirement may be interpreted as, any traffic for the application must use the gateway set for the application.
(1) Simple case, use WAN1 vice WAN2 for the app. Just add another IP route and all traffic will choose one over the other as the destination address is more finite than 0.0.0.0/0 set for the general internet.
(2) Since the requirement is poorly stated/explained, lets assume that you have one subnet that should use WAN1 to access the application and another subnet should use WAN2 to access the same application. Then clearly the above route would not be sufficient.
Hence you need to add a different IP route plan and some route rules.
Yes. Only problem is that Viber’s dst-addr is constantly changing (even between calls in 5mins), so I have to check if dst-addr is resolving to an address contains Viber-specific DNS strings.
Hence, I’d freeze the connection while this string comparison and reverse DNS request is being run, and only proceed when these are finished.
This whole operation I don’t want to be enabled by default, so I’d start something on the Tik to activate this and immediately stop it once the connection has been established.
(When connection has been established, dst-addr doesn’t change during that paricular call)
You cannot put processing of a packet on hold, but normally the protocol stack (in case of TCP connection) or the application (in case of UDP connection) takes more than a single attempt to initiate a connection before giving up. So dropping the very first packet of each connection should not be too harmful. You can schedule the analytic script for every second so in the worst case, it will take less than two seconds for new connections to establish. If that is too long, you have to let the analytic script run in a loop rather than spawning it using a scheduler.
I can think of at least two different ways to do this that would be better then your way. Let’s get some more information. Is Viber running on phones or desktop?
Since @extended made this 10x easier, now you know what to do.
Firewall list with Viber users. PBR based on ports from article with source address of firewall list. (I would do a packet capture to confirm that hasn't changed, as not all those ports are listed in the viber article of ports.) and then you will have successfully simplified your experiment.
Please note this is 5 years old. Viber has changed a lot since then.
These assumptions are simply not working (well) anymore.
Viber is now hosted on Amazon Cloud and it uses different and very frequently chaning IP addresses.
My intention is to use it both on phone and PC.
Half year ago for Viber Desktop it was enough some port forwards. But not anymore.
Even sending an image fails both on PC and phone without using my way.
(Note: port forwards might work, but you also have to forward all all outgoing traffic on 80 and 443 ports which would ruin other websites and would waste the other costy gateway’s resources)
Hence I haven’t included Viber in title as it is too hard to properly test with providers who are not blocking it. (I assume vast majority people are using these providers)
So I just wanted to avoid wasting users time and effort on giving me advise on Viber as this could be interesting even without Viber.
The changing destination Ip’s have nothing to do with this problem. I don’t think you understand how much your over complicating this. This is super easy. For the desktop all you need to do is go into advanced firewalling and change the dscp for that viper application. then you can route based on the dscp setting that you chose and the source ip. For the cell phones you would route based on ports and source ip.
If your not interested in doing this the easy way then it’s no skin off my back. There is no port forwarding involved.
Thank you, I appreciate your efforts, and yes, I might be wrong, sorry for the confusion. Can you give me some hints on how exactly can I set DSCP for the Viber application?
My investigation led to this (not related to DSCP at all): Viber needs to communicate with their servers on AWS. It’s not enough to route only the RTP packets, I found it’s also mandatory to route it’s link to AWS (done via standard HTTPS).
To understand more my problem: my ISP is heavily blocking Viber’s traffic. Not only VoIP, but all data related traffic, so almost nothing works: only basic text send/receive, but more complex data transmission is banned (images, voice recordings), and of course real time audio and video for sure.
So I don’t just need to route the realtime media, but also I have to route the maintenance connections with AWS. And as these maintenance connections are using 443, I can’t really distinguish which packets shall route where, unless I’m collecting the suspicious dst IPs, and then sooner or later I’ll have a list with all used IPs.
As I highlighted: my solution works 100%, but it’s tidious. So I’m very well opened for literally anything, which can help making it easier / faster / better.
I did not know windows 10 home had those limitations. I guess I was wrong and your way as convuluted as it is, is the current best way to deal with this, while using mikrotik anyway.
