I am a newbie at PowerShell but wouldn't ask without spending a ton of time looking online first.
Is there any possible way of specifying ipv4 DNS Server (and alternate) without being connected to the VPN first?
I am installing VPN profile for a business which I can do manually but there is close to 180 users which I am trying to implement through a PowerShell script in Endpoint Configuration Manager. I am obviously trying to work smarter, not harder.
I already have the Add-VpnConnection script down which works great but I still have to manually change the Primary and Alternate DNS for ipv4.
In addition, I would like to turn off ipv6 for this VPN but that coincides with this originally problem I am running across.
Any help or ideas down the right path would be much appreciated!
I have tried to set a reverse SSH tunnel access from a Windows client so i can RDP into his system without its firewall/NAT bugging me, but the problem I have is that when the user does a reverse SSH tunnel (doing -R option in ssh) to my linux system from windows, its basically like he is doing a SSH to me and can do commands and do whatever, but i only want this SSH connection to serve as a tunnel, so user can't do anything and tunnel being used only for doing RDP and bypassing the firewall
so how can i restrict the connected user from doing anything, and forcing this connection to only be used for the reverse RDP? because as of right now when he connects, he can type any command and has the current access
and no i dont want to solve this by hide the CMD, i want to stop all the access from user.
as of right he is doing ssh -R ... in his cmd, and again, i don't want to solve this by just hiding the window, so don't want to add the -fN option either.
also i want to solution to be without any need to install a third-party software on the client, so i have to use the windows 10's build in features
I have a client who is remote. I need to debug some weird problem that none of my other clients are having. Before I try and set up a conference with this client, I would like to know if there is some way of remotely debugging our application.
I see that there are remote debugging tools available for Visual Studio, but from what I've read, I need to be on the same subnet. As the person is remote, this is not a possibility. Also, as I'd like to keep our connection secure, I would need to connect up some sort of encrypted tunnel (this is where I'm a little fuzzy as my networking skills are mostly theoretical).
As I understand it, an encrypted tunnel is a bridge to another (different) subnet. This is to ensure that those computers on the other side won't interfere with the local subnet computers.
So, because the client's computer is on a different subnet, I think that this is not possible. Or is it? Should there not be a way of making the client's computer show up as a virtual computer on my subnet, by forwarding packets from one subnet to another? I would think that this is theoretically possible, but I'm not exactly sure how I would go about this.
Also, at the moment, my current way that we connect to clients is through GoToMeeting, but I don't think that it supports tunneling. If not, then I may need some way of generating a tunnel, so I was also thinking of maybe using some SSH programme like PuTTY.
As I have said before, my knowledge of networking is quite theoretical, so if the tools that I am suggesting are not the correct ones, please correct me. (I'm a programmer, damm it! Not a network engineer!)
Both computers are Windows boxes. Windows 10 (client) and Windows 8.1 (development).
If you can connect to an ssh server in the remote network, you can (subject to configuration on the server) create a tunnel such that you connect to a socket on your local pic and the connection appears from the server to an endpoint on the remote network.
You'll want to investigate the -L command of OpenSSH, which combined with the PuTTY docs, should help explain what's required.
By default, the endpoint would be a port on the ssh server, but it could be a port on a different host that the remote server can connect to.
I'm not familiar with the current state of Windows SSH servers, but even if there isn't a system server to hand, you should be able to have on run 'on demand' - if you run it on a non-privileged port and by the user you want to connect in as, it shouldn't even need Admin privileges.
I'm not familiar with GoToMeeting, but the one thing with SSH tunnelling it that IT depts should be familiar with SSH. If trying that, focus on getting a working connection in, then setting up the tunnel, then connecting through it as separate steps.
Once you have an SSH connection, then it doesn't need to do something itself, and you can then investigate connecting while specifying the port forwarding, but will will need to get the basic connection working correctly first.
I have a few VPN servers and I find it quite tedious to create several configurations for each server.
In a perfect world I'd love to do something like this:
pptp 168.24.15.65 username password
And that would connect me right away, is this doable?
pppd pty "pptp SERVER --nolaunchpppd" file /etc/ppp/options.pptp user USER password PASSWORD
require-mppe-128 option (could be enabled in options.pptp) is often needed for windows servers.
After connection usually configuration of routing is needed. Something like this:
ip route add 10/8 dev ppp0
I need to start a process and keep it running on several remote windows (03 and 08) servers.
When I telnet in and start the process and sign out of my telnet session, the process dies.
I changed the registry settings so the pertinent tlntadmn output looks like this:
End tasks on disconnect : NO
restarting the service and/or rebooting the server have had no effect. My processes still die when the telnet session ends.
Any advice?
My advice would be to ask this question at serverfault.com, which is similar to SO but focuses on sysadmin stuff. As I know near nothing about telnet, if you can't figure this out take a look at PsExec, which will let you run executables on remote machines in various ways.