So two further days of usage and the vpn has been working properly again. At the end the day, I had reverted back to original settings so everything just apparently started to work back on its own??

Really not sure what was causing the issue.

@dafyre said in ZeroTier vs VPN:

@Romo -- If this is a full scale RDS setup, you could also set up the RDGW (Remote Desktop Gateway) and not have to use ZT

That would involve added licensing no?

---

So what they where doing is basically port forwarding rdp to the server and the other desktops. Their current router/ap combo that acts as a gateway can't do any sort of VPN. We tried getting a Zyxel USG40 they had in storage up and running as their new gateway, but it appears to have been setup previously (wrongly) and we couldn't get it to reset to factory settings yesterday.

So I did end up setting up a zerotier test for him on two machines (he needed the access) so he could test it out and see how it worked for him. He did really like the ease of setup, as he even messaged me again when he installed the ZeroTier client on the remote system and how he easily joined the machine to the network and authed the machine once it appeared in the management portal.

I'll talk with him later today and hear more of his opinion.

Considering this use case:

Remote users wanting to RDP into

• Main Server (this will really be the main place to connect)
• Accounting user's pc
• Owner's pc

When would using ZeroTier be a better idea than setting up a remote access VPN (L2TP/IPSec)? Would this case be a proper case to use it considering the whole lan is not necessary to be accessible?

What are your opinions about this

This was working properly until we switched to ATT. It is still properly reaching the router and also authenticating correctly to the radius server. It's just after connecting it completely craps out.

Ok even weirder behavior now, currently I am getting steady pings for a very short period of time and then the connections just seems to die.

MTU is currently set to 1472

Pinging 10.10.10.1 with 32 bytes of data:
Reply from 10.10.10.1: bytes=32 time=87ms TTL=127
Reply from 10.10.10.1: bytes=32 time=89ms TTL=127
Reply from 10.10.10.1: bytes=32 time=87ms TTL=127
Reply from 10.10.10.1: bytes=32 time=89ms TTL=127
Reply from 10.10.10.1: bytes=32 time=90ms TTL=127
Reply from 10.10.10.1: bytes=32 time=88ms TTL=127
Reply from 10.10.10.1: bytes=32 time=87ms TTL=127
Reply from 10.10.10.1: bytes=32 time=88ms TTL=127
Reply from 10.10.10.1: bytes=32 time=93ms TTL=127
Reply from 10.10.10.1: bytes=32 time=93ms TTL=127
Reply from 10.10.10.1: bytes=32 time=94ms TTL=127
Reply from 10.10.10.1: bytes=32 time=91ms TTL=127
Reply from 10.10.10.1: bytes=32 time=88ms TTL=127
Reply from 10.10.10.1: bytes=32 time=87ms TTL=127
Reply from 10.10.10.1: bytes=32 time=93ms TTL=127
Reply from 10.10.10.1: bytes=32 time=95ms TTL=127
Reply from 10.10.10.1: bytes=32 time=91ms TTL=127
Reply from 10.10.10.1: bytes=32 time=90ms TTL=127
Reply from 10.10.10.1: bytes=32 time=101ms TTL=127
Reply from 10.10.10.1: bytes=32 time=89ms TTL=127
Reply from 10.10.10.1: bytes=32 time=88ms TTL=127
Reply from 10.10.10.1: bytes=32 time=88ms TTL=127
Reply from 10.10.10.1: bytes=32 time=89ms TTL=127
Reply from 10.10.10.1: bytes=32 time=106ms TTL=127
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

During that initial time, when the connection has just established web browsing also works close to normal speeds I would say. Really strange behavior.

Been playing for the value for a while and still no luck. I am still seeing packet loss.

Edge router logs have been showing:

May  7 18:00:48 office pppd[24483]: pppd 2.4.7 started by root, uid 0
May  7 18:00:48 office pppd[24483]: Connect: ppp0 <-->
May  7 18:00:48 office pppd[24483]: Overriding mtu 1500 to 1474
May  7 18:00:48 office pppd[24483]: Overriding mru 1500 to mtu value 1474
May  7 18:00:50 office pppd[24483]: Unsupported protocol 'IPv6 Control Protocol' (0x8057) received
May  7 18:00:50 office pppd[24483]: Unsupported protocol 'Compression Control Protocol' (0x80fd) received
May  7 18:00:51 office pppd[24483]: Cannot determine ethernet address for proxy ARP
May  7 18:00:51 office pppd[24483]: local  IP address 10.255.255.0
May  7 18:00:51 office pppd[24483]: remote IP address 192.168.4.10
May  7 18:03:45 office pppd[24483]: Overriding mtu 1500 to 1474
May  7 18:03:45 office pppd[24483]: Overriding mru 1500 to mtu value 1474

Any other ideas?

@JaredBusch said in Packet loss when connected to L2TP/IPsec VPn:

@Romo said in Packet loss when connected to L2TP/IPsec VPn:

@dafyre said in Packet loss when connected to L2TP/IPsec VPn:

Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.

Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492

UVerse? Then your service is PPPoE. You likely need to lower the MTU to account for it.

Also If UVerse, you are screwed in your router options.

How low should I go, or is it just a matter of testing? Currently at 1400, web browsing is still not working properly.

Tracing route to 10.10.10.1
over a maximum of 30 hops:

  1     *      105 ms   102 ms  10.255.255.0
  2   118 ms   104 ms   102 ms  10.10.10.1

Trace complete.
PS C:\WINDOWS\system32> tracert 10.10.10.1

Tracing route to 10.10.10.1
over a maximum of 30 hops:

  1   106 ms   106 ms     *     10.255.255.0
  2   116 ms     *        *     10.10.10.1
  3   103 ms   109 ms   121 ms  10.10.10.1

@dafyre said in Packet loss when connected to L2TP/IPsec VPn:

Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.

Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492

This is remote access not site to site by the way. I have indeed restarted the vpn and packet loss still is there.

Had a working remote access vpn setup on an edge router lite, but this weekend we changed our main ISP from Comcast to ATT. The only change made to the working config was the outside-address setting which now points to the new ATT ip everything else is exactly the same.

Today users where reporting that the VPN was really slow, windows shares wouldn't open for them and web browsing was also not working. When I remoted into one of the machines, it was indeed barely working when connected to the vpn, the remote session was having lots of trouble being open.

I set up the vpn on a test vm and starting pinging the file share:

Ping

Ping statistics for 10.10.10.1:
    Packets: Sent = 195, Received = 109, Lost = 86 (44% loss),
Approximate round trip times in milli-seconds:
    Minimum = 87ms, Maximum = 238ms, Average = 103ms

Tracert

Tracing route to 10.10.10.1
over a maximum of 30 hops:

  1     *       98 ms   102 ms  10.255.255.0
  2    96 ms     *        *     10.10.10.1
  3    93 ms    96 ms     *     10.10.10.1
  4     *        *      106 ms  10.10.10.1

Any idea what could be causing this issue? Also seems strange the tracert reaches the server 3 times for some reason.

Could this be the provider? this only started after the change to ATT, with comcast everything was working properly.

USG-XG-8 is the one that is getting it production halted at least from this: https://community.ubnt.com/t5/UniFi-Updates-Blog/USG-XG-8-Product-Status-Update/ba-p/2734268

You can actually install it using the WSL and/or Cygwin, I posted some screenshots I think on 2017, it didn't all work back then so it might be worth it to revisit it and test it out

WSL

CYGWIN

Edit: heres the post back then https://mangolassi.it/post/359372

Great Job @EddieJennings !!, Really liked the flow and tempo of the video

@Obsolesce said in What Are You Doing Right Now:

@scottalanmiller said in What Are You Doing Right Now:

@Obsolesce I love European playgrounds.

@scottalanmiller said in What Are You Doing Right Now:

@Obsolesce I love European playgrounds.

Ya there's so many good ones. We went to this one on Saturday.

http://www.uppsalaslekparker.se/pelle-svanslos-lekplats-pelleparken-uppsala/

That is super nice!!

Happy Birthday @pchiodo

@valentina Aren't those super little?

@Obsolesce Haven't tried it by running it directly as SYSTEM, it has been run as a user and checked to be run with the highest privileges. As it was when it was working before.

@EddieJennings yes destination has enough storage, shares are writable as well as running the script manually works without an issue.

Ok finally something new, apparently something is wrong with the destination folder as I am getting:

So through Task scheduler it cant write to the destination folder for some reason.

@Obsolesce said in Robocopy script not running from task scheduler:

@Romo said in Robocopy script not running from task scheduler:

@JasGot Same account currently as the user running the script manually. Also forgot to mention it had been working before without adding net use and the UNC until someone else tried to make a modification.

If it was working before and then stopped working when nothing was changed, that smells like a Windows update messed things up.

Yeah, it could be a possibility. Something in the task was changed though but not sure exactly what was changed. We were told a couple of days after it had stopped working.

What I really find strange is that the scripts works just fine when manually run. We must be missing something somewhere that makes the script fail on task scheduler.

Maybe when running through task scheduler it can't access the credentials in Credential manager until something is executed beforehand??