Redirect Internet traffic through tunnel based on port

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Weggy

Regular Contributor
Hi,

I'd like to control the direction traffic goes in based on the port of that traffic. Is this possible?

For example, all traffic on port 80 would be "unchanged" / "normal". While all traffic on port "3000" would go via a VPN client.

As a note, I already have defined via the VPN Director for traffic from certain IPs to go via the VPN, but what I really require is traffic on a specific port from that client to go via the VPN.

Any help appreciated.
 

Torson

Senior Member
Hi,

I'd like to control the direction traffic goes in based on the port of that traffic. Is this possible?

For example, all traffic on port 80 would be "unchanged" / "normal". While all traffic on port "3000" would go via a VPN client.

As a note, I already have defined via the VPN Director for traffic from certain IPs to go via the VPN, but what I really require is traffic on a specific port from that client to go via the VPN.

Any help appreciated.
Port based selective routing has been brought up a number of times. I don't recall seeing a script based method of doing that.

The closest match would be here https://github.com/RMerl/asuswrt-merlin.ng/wiki/Policy-based-Port-routing-(manual-method)
 

Martineau

Part of the Furniture
Port based selective routing has been brought up a number of times. I don't recall seeing a script based method of doing that.
Perhaps you didn't look hard enough! :cool: :p
Code:
#!/bin/sh
VER="v1.10"
#======================================================================================================= © 2016-2021 Martineau, v1.10
# Selective PORT routing to VPN (will use VPN DNS if VPN Client is in DNS 'Exclusive' mode)
#                        or WAN if say a NAS is forced out via the VPN
#
#   e.g.   VPN_PortSelect   [status|status full] | [help|-h] |
#                           { 0 | 1 | 2 | 3 | 4 | 5 | 9} { IP_Address_list | host_name_list | all | mac_address} { [!]port1[,port2] ['udp'] ['logfwmark']} ['src'|'dst]'
#                           ['del'|'test'|'nodns'] ['forcerpf']
#
#          VPN_PortSelect   2 hp-envy14 80,443
#                           TCP Ports 80 and 443 for the HP-Envy14 device will be routed via VPN Client 2 and HP-Envy14 device will now use VPN DNS
#                           Check using https://ipleak.net/ or http://whatismyipaddress.com/ or issue 'curl "http://ipecho.net/plain";echo'
#          VPN_PortSelect   2 hp-envy14 80,443 del
#                           TCP Ports 80 and 443 for the HP-Envy14 device will be no longer be routed via VPN Client 2
#          VPN_PortSelect   2 hp-envy14 80,443 nodns
#                           TCP Ports 80 and 443 for the HP-Envy14 device will be routed via VPN Client 2 and HP-Envy14 device will continue to use WAN DNS
#          VPN_PortSelect   1 12:34:de:ad:00:00 80,443
#                           TCP Ports 80 and 443 for the device with MAC address 12:34:de:ad:00:00 will be routed via VPN Client 1
#          VPN_PortSelect   1 12:34:de:ad:00:00 80,443 logfwmark
#                           TCP Ports 80 and 443 for the device with MAC address 12:34:de:ad:00:00 will be routed via VPN Client 1 and iptable LOG messages sent to Syslog
#          VPN_PortSelect   2 hp-envy13,hpenvy14 !80,443
#                           ALL TCP Ports except ports 80 and 443 for both the HP-Envy13 and HP-Envy14 devices will be routed via VPN Client 2
#          VPN_PortSelect   2 10.88.8.66 22,9001:9005
#                           TCP Ports 22 and 9001 thru 9005 for the 10.88.8.66 device will be routed via VPN Client 2
#          VPN_PortSelect   0 10.88.8.66 3389 udp src
#                           UDP Port 3389 for the 10.88.8.66 device will be routed inbound via WAN (assuming 3389 has port forward in GUI)
#          VPN_PortSelect   0 all 80,443
#                           TCP Ports 80 and 443 for all devices will be routed via WAN
#                           (Assumes that ALL traffic is via the VPN!!!)
#          VPN_PortSelect   0 all 5000,5001 src
#                           TCP Ports 5000 and 5001 will be routed IN via WAN assuming Port Forwarding is also configured!
#                           (Assumes that ALL outbound traffic from the NAS is via the VPN!!!)
#          VPN_PortSelect   1 cameras 80,8080
#                           TCP Ports 80 and 8080 for the 'cameras' device group will be routed via VPN Client 1
#                           (Assumes /jffs/configs/IPGroups exists with valid pair entry - Uppercase text!)
#                                    e.g. CAMERAS  10.88.8.11:10.88.8.13
#                                         or
#                                         PHONES   10.88.8.156,10.88.8.172
#
#
 

Torson

Senior Member

Weggy

Regular Contributor
Okay, so it is possible? Now a dumb question I expect, what do I do with the above?

Does it get entered into my "Custom Configuration" section. Or do I apply it some other way? I've not messed with this before.
 

Weggy

Regular Contributor
On another note, given this request has come up previously. I assume RMerlin said it's not possible to better integrate such a feature? (I.E. easily utilised via the user interface) I know sometimes there are restrictions not that I understand them. Do you know if anyone asked?
 

eibgrad

Very Senior Member
On another note, given this request has come up previously. I assume RMerlin said it's not possible to better integrate such a feature? (I.E. easily utilised via the user interface) I know sometimes there are restrictions not that I understand them. Do you know if anyone asked?

Merlin does NOT use the marking of packets, but instead, adds/removes ip rules. These rules do NOT include the ability to specify ports, but are limited to a few items, such as source and/or destination IP (there are others like TOS, but those are not relevant at the moment).

If he decided to switch to marking packets instead of ip rules, he would then face the problem of making sure other parts of the system don't interfere w/ his marks, and vice versa. And that's because there's only *one* location for marking packets that's shared by all processes. All participants in marking are expected to *cooperate* and NOT mess up the marks of others. And you do that by a) reserving certain bits within the marked field for yourself that are known NOT to be used by others, and b) masking your marks so you don't mess up the marks of others.

Problem is, trying to enforce those two things is next to impossible when you have a mix of OEM and third-party developers who are all working independently. Even those offering their own scripts, or suggestions for how YOU can implement policy based routing based on marking, are taking a risk that some unknown process doesn't mess w/ your marks, or vice versa. That's why this is a bit trickier to implement than some would have you believe. To the extent you can guarantee that only YOU are marking packets, you can do so w/ 100% confidence. But that almost never happens. I've seen everything from unexpected usage of certain bits in the marked field, to processes that clobber anything they find, as if they expect exclusive use.

This is one of the reasons I've been reluctant to mark packets over the years w/ third-party firmware. Sometimes you can get away with it if you know the firmware quite well, or else notify users that certain other features that also depend on marking can not be used at the same time. But if you just assume otherwise, you can quickly make a mess of things. And even when you do know the firmware quite well, things can suddenly change w/o your knowledge.

Now granted, someone like Merlin is far better positioned to avoid such issues than you or I. But even so. It's far easier for him to simply add/remove IP rules at will, since rarely is anything else in the system doing the same. Conflicts are very rare.

FWIW, FreshTomato implements policy based routing using marked packets. But they do NOT offer anything more than source/destination IP (well, they do offer domain name support, but that's implemented w/ a combination of ipset and marking, and that's another story). So in that case, it would presumably be easier to add support for ports by just changing the GUI. But in all the years they've supported policy based routing, they've never indicated any such desire or intent. But at least the firmware developers are in FULL control of what is using marks. OTOH, Merlin has to integrate his changes w/ both open and closed sources from ASUS, giving him significantly less control.

All that said, I'm sure another big part of the decision is just the desire to keep things simple. Every developer, esp. any dealing w/ a GUI, has to draw a fine line between functionality and ease of use, and avoid the problem of making the GUI so complex, it becomes intimidating to end-users, and difficult to support. The number of users that need port support is probably just not at a threshold to overcome those concerns (which probably explains why FreshTomato still doesn't support it either).

JMTC
 

Martineau

Part of the Furniture
On another note, given this request has come up previously. I assume RMerlin said it's not possible to better integrate such a feature? (I.E. easily utilised via the user interface) I know sometimes there are restrictions not that I understand them.
Do you know if anyone asked?
The continued successful use (since 2016) of 'unauthorised' fwmarks for RPDB Selective Routing of Ports (using scripts) almost seemed to be rendered obsolete as described in my 7-month old March 2021 bug post
Although raised for the RT-AC86U HND router (with the v4.1.27 Kernel) it may still be beyond @RMerlin's and ASUS' control to at least allow scripts to exploit the preferred RPDB (iproute2) based solution even if it is still deemed too niche to be added to the GUI.?

NOTE: Not sure if the flagship AX router Kernel (RC3) now allows the selective iproute2 RPDB sport / dport feature to be successfully used in scripts when available?
 
Last edited:

Weggy

Regular Contributor
This all sounds great but I understand none of it haha

I'm guessing overall what appears simple (i.e. control your traffic), is a lot more difficult in practice.
 

RMerlin

Asuswrt-Merlin dev
NOTE: Not sure if the flagship AX router Kernel (RC3) now allows the selective iproute2 RPDB sport / dport feature to be successfully used in scripts when available?
iproute2 documentation is horrible when it comes to documenting what kernel version is required for specific features, but I have a feeling that port support in ip rule was only added with kernel 5.x. So, Asuswrt support isn't going to happen, kernels don't get updated by Asus, only by BCM and only when they release a new SDK for a new platform.

Trying to use a port with 4.1.51 caused a kernel crash when I tried it.
 

eibgrad

Very Senior Member
iproute2 documentation is horrible when it comes to documenting what kernel version is required for specific features, but I have a feeling that port support in ip rule was only added with kernel 5.x. So, Asuswrt support isn't going to happen, kernels don't get updated by Asus, only by BCM and only when they release a new SDK for a new platform.

Trying to use a port with 4.1.51 caused a kernel crash when I tried it.

FYI. I don't know how he did it, but Brainslayer @ DD-WRT managed to backport the sport/dport features of ip rule from 4.17 to older kernels.


Never bothered to use it myself, and it does seem a bit awkward to implement based on the documentation. But for those end-users interested, it's an option I suppose.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top