I didn't provide all of the details, because it didn't matter for a recommendation. However, the user does in fact need Windows on both the laptop
The recommendations are based on the original bit. RDP alone has essentially no requirements at all. But if they need to do other things, then that would be the driver of requirements, RDP is a red herring.
That's fair, it does conflict because I said "just needs RDP".
I pulled the trigger on a cheapo Dell Refurb. Will do great for this specific scenario. Thanks gentlemen!
@scottalanmiller Yeah, Our team, when working from home, likes to RDP into their PCs at the office. They use either traditional VPN, or Zerotier. Some of them claim to have issues with Zerotier, claiming it is "slow" for them. I never use traditional VPN anymore and I only use Zerotier if I have to RDP to anything at the office. I never experience slowness of any kind with Zerotier.
Yeah, change is "hard" 🙂
🙂 Zerotier is was such a game changer for us. Remember the old MPLS / pay a fortune days? DO NOT miss those.
I've never had to deal with that. We had better options than MPLS before MPLS hit the market. Even by 2000 we had ways to handle that stuff well without MPLS.
Yeah I only dealt with MPLS in a larger global company I worked for previously. They spend SOOO much money on AT&T managed WAN connections. Like insane amounts of money.
The first few were about 10 years ago, but that fun is done. Now its just a PITA, but with HIPAA and all, I figured better safe than sorry...
Check with your shredding company. Many of them will accept drives in the shred truck the comes by.
One of my clients does this. The shredding company jsut wants to know when drives are involved prior to arrival so they can make it first stop or last stop, i forget which. Because hot metal and paper = potential fire.
I think it is last stop. so they can easily extinguish if needed.
That's really just nmap. Nothing wrong with using it, it is the official GUI frontend for nmap.
Yeah but saves me learning nmap commands 😆
That too. I use nmap a lot from the command line, but I'm normally running a standard scan (no options, just nmap xxx.xxx.xxx.xxx) or looking for a specific port nmap -p 443 xxx.xxx.xxx.xxx covers 90% of what I use it for.
Phew! Busy couple of days for me. Sorry for the late reply.
OK, so the setup is as @JaredBusch assumed. VPN on the Laptop only. Split tunneling was not enabled and now it is. Problem solved for now! DuckDNS is reporting the correct home IP. No need for VPN on the phone or PBX.
This one was interesting to get to the bottom of. @JaredBusch With the VPN tunnel enabled, the phone system was trying to send RTP to the phone on the internal IP. There is a setting in FreePBX on the extension level called "RTP Symmetric". Normally, this is set to yes. I changed it to no and the audio started flowing normally. However, I didn't like this solution. So, as a test, (and what I should have done from the beginning) I blocked all outbound traffic FROM my phone system, to any local network. (10.x, 172.16, 192.168, etc) This immediately solved the issue. I did not yet do a packet capture AFTER the fact to confirm, but I am assuming that blocking the PBX's ability to get to an internal private IP, forces the system to renegotiate and send the RTP to the correct public IP.
Definitely an odd issue.
nice you found a solution - I'm curious why it happens in the first place? Are some of the original phone's packet data still containing the original IP? And if so, why?
Are you using encrypted RTP?
@fuznutz04 : Keep an eye out for the "hidden" hibernate that doesn't show up under "Plan settings" (only sleep and display). I've seen multiple systems that have "Hibernate after" configured under "Sleep" in the advanced settings as default.
There's also the problem where some systems become broken and once a system goes to sleep, it will continue going to sleep no matter what after something like 2 mins of non use. Rebooting fixes it, until it goes to sleep again... there is a fix somewhere in these threads too, reg fix.
After this, all of the strange event viewer errors in the DNS log, AD log, etc were gone. I can now successfully replicate across sites as well as join PCs to the domain. I'm not sure why this happened in the first place, but this fixed it.