With shadowsocks as default proxy, can "Use V2Ray" be checked in Network-Firewall-Port Forwards?

[Network-Traditions]

Expected Behavior

With the OpenMPTCProuter wizard advanced settings "default proxy" set to "shadowsocks", "Use V2Ray" may still be checked and used for port forwards in the advanced settings tab of the port forwards tab of the firewall section of the Network configuration.

Current Behavior

With such a configuration, numerous time outs are occurring as follows:

Tue Oct 4 23:26:15 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:23 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:25 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:27 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:27 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:34 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:42 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:48 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:54 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:27:02 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out

@Ysurac stated the following in #2382:

And there is a problem in one log there is ss-redir problems, it's about shadowsocks, and in latest log it's about v2ray. Check that you don't have both running if you set them manually.

Does this mean when using "Shadowsocks" as the "Default proxy", the use of V2Ray should be completely avoided? If so, is there anything wrong with configuring a port forward with "Shadowsocks" as the "Default proxy" consistent with the "Port forwarding using v2ray" webpage on the website, but simply leaving the "Use V2Ray" box unchecked and not having the NAT rule as documented on the "Redirect port via VPN on OpenMPTCProuter" webpage? We are testing this approach and it seems to be working, but were still getting a lot of the aforementioned "time outs".

Specifications

OpenMPTCProuter: v0.59.1-5.4 r0+16594-ce92de8c8c OpenMPTCProuter VPS version: Debian 11 5.4.207-mptcp VPS 0.1028 Architecture: x86-64 OpenMPTCProuter VPS provider: IONOS.com 2 vCore 2GB RAM "Type M VPS" OpenMPTCProuter platform: x86_64 Intel® Celeron® Processor J4125 with 4 Intel i225 "B3" NICs T-Mobile 5G Business Internet Telit modem in USB 3.0 sled with static publicly reachable IP StarLink version 2 configured as Ethernet bridge with a CGNAT non-publicly reachable IP

[Ysurac]

When Shadowsocks proxy is used, V2Ray can't be used at the same time. Checkbox in firewall to use v2ray is ignored in this case. The SNAT rule is often needed for web servers, but not required in all other cases.

[Network-Traditions]

@Ysurac thanks! With the default proxy set as ShadowSocks and multiple system log entries back to back as follows:

Tue Oct 4 23:26:15 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:23 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:25 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:27 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:27 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:34 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:42 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:48 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:26:54 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out Tue Oct 4 23:27:02 2022 daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out

When do these entries become a concern? Always, only when they come in back to back multiples, when accompanied with other issues such as localhost admin script loss of contact, etc? If this is something to be resolved, what should I be investigating?

[Network-Traditions]

@Ysurac while testing the impact of the "Master interface selection", which during the aforementioned accumulation of:

daemon.err /usr/bin/ss-redir[18807]: remote recv: Operation timed out

Starlink was set as the master with T-Mobile enabled using "Balancing". Switching to "Latency", OMR changed the master to the T-Mobile interface and the "time outs" disappeared from the OMR system logs. I then proceeded to test the "No change" selection with the same no "time outs" results. I considered the idea that Starlink experiences numerous mini-disconnects throughout the day so I was thinking that may be causing these log entries.

I'm now experimenting with the "Use broadcast flag" in the "Advanced Settings" tab of the Starlink WAN2 interface. With that option checked and Starlink reset to the master interface using the "Balancing" Master interface selection, synthetic speedtest.net cycles no longer are generating the log entries as well. Since I restarted Starlink's WAN2 eth2 interface when I engaged the "Use broadcast flag", it's entirely possible that's what stabilized Starlink as the "Master interface". I will test Starlink with and without the "Use broadcast flag" to see if I can establish it's impact on a bridged Ethernet Starlink v2 connection. If anything valuable is gained from those efforts I will post them here.

[Network-Traditions]

@Ysurac we achieved reasonably stable performance with 75% of maximum throughput at an acceptable quality and latency from our high visibility StarLink and low grade signal T-Mobile WAN connections using ShadowSocks as our default proxy, which was required to sucessfully route outbound UDP/RTP packets from our Asterisk/FreePBX server though pfSense and OMR to the endpoint device (V2Ray was dropping these packets for unknown reasons). Since we've switched to ShadowSocks, the OMR system log is littered with the aforementioned, "daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out" (did not occur with V2Ray as default proxy). While taking a deeper dive into our system log today and tagging IP and NIC references along with evaluating timestamps, we noticed the following issues:

Time	Duration	Lease	Description
9:45:23			daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
9:45:23	0:00:00		daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
9:47:53	0:02:30		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
9:47:53	0:00:00	0:02:30	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
9:50:23	0:02:30		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
9:50:23	0:00:00	0:02:30	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
9:52:53	0:02:30		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
9:52:53	0:00:00	0:02:30	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
9:55:24	0:02:31		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
9:55:24	0:00:00	0:02:31	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
9:55:48	0:00:24		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
9:57:54	0:02:06		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
9:57:54	0:00:00	0:02:30	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
9:58:35	0:00:41		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
10:00:00	0:01:25		user.info vnstat_backup: backing up database
10:00:24	0:00:24		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
10:00:24	0:00:00	0:02:30	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
10:01:31	0:01:07		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
10:01:42	0:00:11		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
10:02:54	0:01:12		daemon.notice netifd: wan2 (8003): udhcpc: sending renew to StarLink Gateway
10:02:54	0:00:00	0:02:30	daemon.notice netifd: wan2 (8003): udhcpc: lease of StarLink IP Address obtained, lease time 300
10:03:56	0:01:02		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
10:04:31	0:00:35		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
10:05:18	0:00:47		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out
10:05:22	0:00:04		daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out

1. The system log is also loaded with wan2: udhcpc: sending renew and wan2 udhcpc: lease obtained, lease time 300 entries (wan2 is the StarLink Ethernet connection).

• This has been informative in realizing StarLink has a very short "lease time".
• Review of the renew/obtained lease cycle consistently and successfully completes ever 150 seconds plus or minus 1 second.

2. Any time a change is implemented in the OMR configuration to include but not be limited to, interface, MPTCP, OMR Advanced Settings, etc., the daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out entries disappear for a while, but inevitably return.
3. A review of the StarLink APP outages for the same time period represented above, documents a number of less than 1 second interruptions of service due to obstruction (most common), no signal received or a network issue. These entries do not directly line up with the daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out entries, but they are in close proximity (less than a minute, which could be within the timestamp deviation between the logging systems) some of the time.

Can you provide more information regarding the daemon.err /usr/bin/ss-redir[16449]: remote recv: Operation timed out entries? What are its causes and respective corrective actions? Finally, is there a circumstance where having these entries would be normal or acceptable?

Thanks again for your efforts!

[Ysurac]

I think you use Starlink without the router ? Never tried that. After a configuration change network, shadowsocks or/and VPN can be restarted so an operation time out seems normal. Shadowsocks can display a remote recv operation timed out in many case, sometimes it's because you try to contact an IP that doesn't answer.

[Network-Traditions]

Yes, StarLink v2 with Ethernet adapter in bridged mode so it provides the WAN2 IP address directly to OMR through it's DHCP service. FYI: To clarify the change of configuration influencing the presence of remote recv: Operation timed out entries, thse entries completely disappear for a while inevitably returning.

I'll see if I can find more specific information regarding the potential cause of the logged error entries. If I do, I'll open a new issue. Take care.