Server side: A VM with ubuntu 16.04 on Apache Cloudstack.
CLient: A physical ubuntu 14.04 machine.
I did a port forwarding for UDP connection in the cloud.
I installed server side from this tutorial.
I can smoothly run server and client side and can ping each other. I wanted to tunnel all client side traffic through VPN, hence in /etc/openvpn/server.conf I uncommented
push "redirect-gateway def1 bypass-dhcp"
But whenever the VPN is up on both sides I lose internet connection on the server side. This is not desired. What could cause this? I see no error. Just the VPn tunnel is the only way the server is contacting.
Any insight would be helpful.
Try to Diagnosis the VPN and delete all cookies and temp files from your system, just restart and connect your VPN. Once connected check the log files.
Related
I want to connect via TCP socket a server app running in the host with a client running in the QEmu guest.
I use port 5104 for the socket in the server.
I start the server.
Then I found that I can not launch the QEmu giving that port as the input point for the client in the guest, like this:
qemu-system-arm ... -net user,hostfwd=tcp:127.0.0.1:5104-:5104
Gives the error "Could not setup host forwarding rule ..."
I guess that qemu acts like a server also and then the port is already taken by the server previously launched and then is not possible to do it.
Which is the correct syntax? The documentation talks about the option guestfwd but I tried all the possibilities and I couldn't found the solution. It should be way to do it.
Any suggestion?
What I'm trying to achieve is:
Connect to a VPN as client and route all my internal network's traffic over the VPN.
Run a VPN server, so that people from outside can connect to my internal network and get routed over the a.m. VPN client.
I'm trying to achieve that with a router running dd-wrt (netgear D6200), and / or a raspberry pi.
Can someone tell me if this can be achieved, and if, direct me to what would be a possible solution?
(I'm not looking for a tutorial, just a direction)
Thanks!
This thread probably does not belong here.
Consider using OpenWRT instead of dd-wrt. OpenWRT gives you a usable build system and easier to customize and build. I am not advocating OpenWRT. This can be a stop gap measure.
You can setup a OpenVPN server and OpenVPN client using the standard
documentation available on OpenWRT Wiki and also OpenVPN site.
Add to OpenVPN server.conf the following directive redirect-gateway def1. This will push the default gateway to clients connecting to OpenVPN server. Further, make sure you are using a unique network IP pool for VPN clients and does not clash with the remove VPN server.
Make sure you are masquerading the VPN traffic (Clients of local VPN server) before forwarding to remove VPN server. This can be tricky as this interface does not exist at boot time. It needs to be configured using up and down scripts
Make sure you are allowing traffic (clients of local VPN Server) on VPN interface to be forwarded in your firewall rules
Before setting up the OpenVPN server, make sure
The remove VPN server is pushing the default gateway to your VPN
client
You have setup the firewall correctly
You are able to reach the cloud through the Remote VPN Server. Checking with some site like www.whatismyip.com will help
Yes this is possible with dd-wrt on Netgear.
There is no need of Raspberry (unless you meant to run the remote VPN server on it).
Configure and run VPN server on dd-wrt - and try connectivity by connecting clients. Both tun/tap should work in general (with VPN client running). I tested with tun.
Configure and run VPN client on dd-wrt and try connecting to your VPN server. By default, the router should start directing all traffic (for its own LAN clients) via the VPN server.
So far so good.
The problem comes when you want dd-wrt's VPN clients (and not just LAN clients) to take the same route. With a VPN client running on dd-wrt, dd-wrt's own VPN clients will not be able to connect to the VPN server running on dd-wrt as such. To make it work, see below.
This is only possible via PBR - i.e. you run VPN client on dd-wrt, but take the router itself off this client, and route only specific clients through this VPN client running on dd-wrt.
With some tweaks using subnet masks, it is possible to include all your LAN and VPN IPs in the PBR policy so that everything (except the router itself) routes through the remote VPN server.
The key is to include dd-wrt's VPN clients' virtual IPs in the PBR. While configuring VPN server on dd-wrt, there is a field for specifying the clients' network and netmask.
If you use this network IP and netmask in client process's PBR policy, your (dd-wrt's) VPN clients will be able to connect to the VPN server running on dd-wrt, and will in turn be routed through the remote VPN server to which dd-wrt is connected as a client.
I am Connected to our VPN and I would like to RDP to a Server that is on the network that is currently connected to a different VPN. What do we need to do? If I RDP to a different server and then RDP from that server to the one connected to a different VPN, it works. I just can't directly. Is there something that we need to set up on that server, my computer or the network?
Actually you can be connected to other remote server as well with your machine as VPN client so now will be vpn client to two different vpn server
for doing this you need to perform following steps
1.Create a new client1.conf file for the new remote server
2.copy the content of already present client.conf to client1.conf file
3.now change the value of ca, cert and keys in client1.conf file to the respective values as per to those needed to connect other remote server
4.establish vpn connection with other remote server as follows
openvpn client1.conf
The command used above are for linux to establish vpn using openvpn, For windows, please find same command for windows from openvpn site might be client1.conf in linux corresponds to client1.opvf or something... However this would be the step to be performed in general
I don't have a public ip address so I'm looking to host a server while connected to a VPN, the VPN server is running on a VPS that I own and its running SoftEther VPN server.
In my machine I connect to the VPN and then run the server app, however I check in http://www.canyouseeme.org/ to see if its successfully hosted and can be accessed from internet but its not and it shows "connection refused", if I host the server on the VPS machine it works, but I don't want that, it should be hosted on my machine and should be accessible using the ip address of the VPS/VPN.
You probably want to set up port forwarding on your VPN server.
When you connect to the VPN, your traffic goes through it, but you don't "become" it - the traffic directed to the VPN server (like an attempt to connect to your app) will not be forwarded to your VPN client machine - this is not the purpose of VPNs.
There is a page with port forwarding setup here. This is to be done on the VPN server.
The alternative I use is to setup port forwarding via SSH on the application server and ditch the need for VPN. Check Remote Port Forwarding here. It works fine, encrypts your data between the application server and the gateway, but there might be bigger overhead and it may be more prone to die when the network connection is temporarily lost.
I have got chef-server installed on a centos machine.
Everything is working as expected except that I cannot access the chef-server web interface from another machine on my local network.
I can access the web interface from the centos machine itself:
telnet mychefserver.local 4000
Connected
If I do the same from my machine I have got:
telnet: Unable to connect to remote host: No route to host
I can successfully ping mychefserver.local from my machine
Any idea how to configure nginx with chef-server to access the chef-server from the network?
Since Chef Server 10, the web interface uses normal HTTPS (TCP 443), it only listens on the high ports locally, and nginx proxies as needed to the different backend services. I would try with a normal web browser as telnet isn't exactly great at error messages. Normally I would expect that to mean telnet is getting TCP transmission errors, but maybe it is just confused? If it is really a TCP transmit error then more likely the internal DNS is having issues. .local often means mDNS which has uneven support in some places, I would try an actual IP address to be sure.
My issue was iptables.
I stopped iptables and I can access the chef-server from my local network again.