Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Thu Jul 22, 2021 14:03 Post subject:
Mullvad was kind enough to give me a developers (time limited) account to test with.
I setup a DDWRT router, Netgear R6400v1, build 47087 (alpha build with overclocking, multiple server addresses, reverse PBR, Samba enhancements and more )
Setup a WG client to Mullvad Stockholm which worked fast and easy.
Set a port to forward on the Mullvad website from their Stockholm server to my WG tunnel address.
Set the same port to forward from my router (using manual portforward rule via tunnel) to my NAS.
Set the old Samsung phone on LTE, use Connectbot to connect to the Stockholm server with the port Mullvad gave me and voila I could enter my NAS via telnet and do the housekeeping.
I did this for about 20 minutes to test and no problems with connection.
Further investigation seems to prove - it nothing to do with the VPN provider...
Also, the dropout seems not related to TIME (like X seconds). It is dropping out after a certain number of bytes are transmitted . I will show in next post to here. After my SSH connection is authorized, I get to type 24 bytes (ie chars) into the SSH terminal then it drops out.... I can type them fast, or slow, I will show on the next post - even I type the first 20 chars then go and have a coffee (several minutes) - the connection is STILL UP at that point... but then I type 4 more chars... and the connection drops. EVERY TIME.. totally reproducible.
What I believe is happening: the R7000 thinks a connection is not ESTABLISHED so it removes it from its table of established connections, and subsequently rejecting any incoming packets....
There are 2 explanations I can think of:
1. There is some bug (that I cannot find) in my routes - that causes the reply TCP packets to find another path back to the SSH terminal. There is only one possible other-path (i.e. not by oet2) - that is return traffic going by the regular WAN and not by the only tunnel (oet2). This would mean the first TCP SYN frames never get ACKnowledged, so the router decides that the connection is dead and (as it should) drops subsequent packets.
2. OR - there is some bug in the dd-wrt software that causes it to not know a connection was ESTABLISHED... same result...
Last edited by seanPH on Fri Jul 23, 2021 8:54; edited 4 times in total
Test 01 (35 seconds)
Connect by SSH - enter "ls" command - a few times, until the connection drops:
Test 02 (44 seconds)
Connect by SSH - COUNTING the chars entered... shows connection drops after 24 chars entered:
Test 03 (44 seconds)
Connect by SSH - REPRODUCE Test 02... (it is a different run, note clock in title-bar):
Test 04 (48 seconds)
Connect by SSH - Type 20 chars only - wait 2 minutes (connections still active), then type the remaining 4 chars - and then, as before the connection drops out (note clock in title-bar):
Last edited by seanPH on Fri Jul 23, 2021 8:35; edited 1 time in total
Here are the routes... The SSH connection is being made on port 5479. First is the nat table.
I have confirmed that these SSH connections DO HIT line-number 15 in PREROUTING.
Next is FORWARD chain... Again, I have confirmed that line-number 2 IS HIT by these SSH connections.
All credit and my personal thanks goes to @egc for solving this problem. THANK YOU!
Notes :-
1. My routes (shown above) were CORRECT... ( that was expected, after all the connection was being made successfully, and with bi-directional traffic - just later was a dropout).
2. The analysis logic above, about the connection not being set as ESTABLISHED, as an explanation for the drops out.. was also CORRECT.
3. @egc messaged me: "One thing you can research is the use of SFE /CTF/FA, those are all things which bypass connection tracking so do not use any of that."
The FIX - I was using SFE ( on Setup page under Shortcut Forwarding Engine). I was not using CTF or FA. I just set SFE to disabled and everything immediately started to work as I wanted it to...
Postscript:
1. Still continues to work fully, after enabling both tunnels, to different endpoints from same VPN vendor, using the same keys for both tunnels.
2. It seems little bit slower - my quick measurements (which are probably wrong) seems about 3-5% slower. But no dropouts
3. More on CTF, SFE and FA - here (link provided by @egc) : https://forum.dd-wrt.com/wiki/index.php/Hardware#Flow_Acceleration_and_Cut-Through_Forwarding
4. Hmmm (just speculating here): Should SFE still manage CONNTRACK anyway ?? maybe? I wish it did ! Then would get the faster speed even with this setup... This link ( from the forum ) says it should, but it is hard to know who to believe and what is out of date...
Quote:
Shortcut is an in-Linux-kernel IP packet forwarding engine. It's designed
to offer very high speed IP packet forwarding based on IP connection tracking.
It's dramatically faster than the standard netfilter-based NAT forwarding path
but is designed to synchronise state back to netfilter/conntrack so that it
doesn't need to deal with all of the complexities of special cases.
Seems like SFE is not "synch-ing state info back to conntrack", but that is also a very theoretical discussion. At this point I am just so happy to have a working system !!! yay !! and am looking forward to a good sleep for the first time in many days !
UPDATE -- I now have it set to SFE = CTF , and Flow Acceleration = CTF & FA ...... and it is still working with no drop outs, and the speed is back too (maybe even faster). So it seems the ONLY problem was using SFE.
Thanks again to @egc ! @egc, YOU SIR ARE...
Last edited by seanPH on Sat Jul 24, 2021 12:08; edited 1 time in total
Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Fri Jul 23, 2021 16:45 Post subject:
Great to hear it is solved!
SFE is sometimes known to play tricks with routing, e.g. it should automatically disable when you use unbridged VAP's or VLANs only it does not always do that (I think especially not on Broadcom).
We have been arguing against this disabling as we lose SFE when having an unbridged VAP e.g. for IoT and my testing never showed any adverse effect but this seems to prove indeed it plays tricks !
(BS is right again)
Just for fun you can test CTF + FA, it is possible that that is working better
Have a great day, guys, and I had the kinda same problem with my R7000 router, after using the VPN programs for free. I got this issue:*All - incoming from the internet - connections to oet2 correctly route to destination/port (eg: WOL, SSH, RDP and HTTP/HTTPS), nothing is dropped or blocked. Connections are made via oet2, but then the connection drops out after only 10-15 seconds. * I'm very happy that I found this topic. You guys saved my time with this discussion. The SFE seems to be too tricky for me( The information provided by seanPH about solving his problem helped me much. Once again, thank you both seanPH and egc
Last edited by Knuds on Mon Oct 04, 2021 13:51; edited 1 time in total
seanPH & others
just a FYI--
These forums will NO longer link any 'image' unless the site it is linked to is on a https server.
Not sure when all that changed but twas several months back.
very well ...carry on
---
EDIT:
I grabbed the last image you linked to referring to egc & stuck it on my server
---
Edit again:
What I mentioned is really a 'Chrome' deal ...people using the Chrome browser will NOT see images linked unless they are linked to a HTTPS server ....tis a goofy google people thang ---nothing changed on this oldass forum software
)
