Seeking for knowledge
Does someone have any idea on why this pbdirectory extension is apparently keeping a channel open? Here is the channel detail
Channel: PJSIP/Twilio-000003c5/AGI Up 00:57:30
Exten: pbdirectory CLCID: "" <>
This same issue is happening today once again, VPN is connecting properly but I can't properly reach anything properly on the local lan or the internet.
@JaredBusch said in ZeroTier vs VPN:
@Romo said in ZeroTier vs VPN:
Remote users wanting to RDP into
- Main Server (this will really be the main place to connect)
This is a windows server correct?
Then you need RDS licensing for this no matter what, even to remote into it from in the office. The only reason to use ZeroTier is simply to not expose RDS to the public internet.
Licensing is already set as that is what they have been using internally as well for the users that need to RDP into the server.
From what he told me today, externally he really only wants access for himself to connect to the server as the admin, apparently, he is his own IT.
- Accounting user's pc
- Owner's pc
ZeroTier on these devices is a very typical use case.
He just mentioned a couple of more users but all of them will be only RDP into their own machine as well. Guess zerotier will serve him well without the need to acquire a new router for now.
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
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