Community discussions

MikroTik App
 
User avatar
kiler129
Member
Member
Topic Author
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Semi-randomly change src-port originating from ROS - is it possible?

Thu Jul 29, 2021 5:35 am

So to start I will explain why I'm trying to do that, as it sounds stupid at first.
I have a location with a MT used as a WG client. The throughput is around ~1Mb/s (sic!) despite the network having plenty of bandwidth. When two connections are made the bandwidth is EXACTLY 2x1Mb/s. It turns out the ISP throttles UDP connections based on src-port. I've got a confirmation that it's the case but they're not gonna change that because... reasons. As there are no other ISPs to pick I needed to get creative.

ROS firewall allows for matching n-th packets, so I was wondering how can I change src-port for packets originating at the router? As far as I can see it can only be done in the NAT. However not every packet hits src-nat. Only the first packet hits my src-nat rule and then "connection" is stuck forever in Firewall -> Connections (even with tracking disabled).

Are there any other clever ways of changing src-port of packets except NAT src-nat? I tried marking the packet as "no track" but it can only be seen in Raw -> Output which I believe is too late as it does nothing.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Semi-randomly change src-port originating from ROS - is it possible?

Thu Jul 29, 2021 8:00 am

Even though UDP protocol is stateless per se, applications using it usually take care of state tracking. Which means that application (in your case WG) knows that combination of {src-address1, src-port1, dst-address, dst-port} properties identify a particular WG connection and any packets having the same properties are part of same connection. If application receives a packet with combination of {src-address1, src-port2, dst-address, dst-port}, it shall assume it's about different connection.

So if you'd like to change either of these properties, it would have to be upon mutual agreement of applications on both sides. I highly doubt any application is actually done this way. The other way would be that two NAT functions (one on each end) do it, but again they'd have to be synchronized.

With TCP it's even more a no-go since TCP itself is statefull and already TCP stack takes care of state tracking and the only way for apps to change any of connection properties is to break the connection and establish another connection.

Mind that L6 (actual tunnel payload exchange) might survive TCP/UDP connection break-up/reestablishment and thus traffic through WG might continue to flow without any packet drop, only with a delay spike when L4 connection drops as L5 (session layer) might semi-transparently re-establish needed L4 connection.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Semi-randomly change src-port originating from ROS - is it possible?

Thu Jul 29, 2021 9:41 am

If I remember well, the netfilter module in the kernel does support stateless NAPT (i.e. a per-packet one), but configuration of this feature is not available in RouterOS. But that doesn't matter much as it wouldn't help per se for reasons @mkx has explained.

Instead, try setting up multiple wireguard tunnels between the routers, with a dedicated /interface wireguard item per tunnel at both ends.

If that succeeds, you can use nth to distribute the VPN payload traffic among the interfaces representing those wireguard tunnels, rather than to change the source port of the VPN transport packets.

Of course the rp-filter must not be set to strict in such an arrangement.

If you can distribute the payload traffic per connection rather than per packet, you'll avoid the usual trouble caused by smaller packets overtaking the larger ones in multi-link setups, causing headache to receiving protocol stacks.

Who is online

Users browsing this forum: itamx and 88 guests