Tag Info

Hot answers tagged

2

There are two parts into the solution: 1. Redirect all the traffic into the tunnel The easiest solution - use OpenVPN's --redirect-gateway autolocal option (or put it in the config file as redirect-gateway autolocal. 2. Handle the traffic on the OpenVPN server Now that the tunnel is up all the traffic goes into the tunnel and pops up at the server's end ...


2

A client informed me, that connecting my device, caused another of his systems to lose connection with the network. Could the vpn cause this. Yes, that's possible. What you're describing can be caused by an address space collision - your VPN uses an address range that is also used on the other network, so when the VPN is connected, there is a range ...


2

Well. On the server side, specifying "proto" twice doesn't actually do anything - "proto udp6" will make it bind a dual-stack socket to handle v4+v6, overwriting the "proto udp" in the previous line. On a 2.3 client, having two remotes, with "udp6" and "udp" is the way to go, as the old socket code cannot failover itself properly. On a git master ...


1

a DNS (or DNS-like) service updated with the mapping {client-name => current ip address} Handing this on the OpenVPN server(s) is relatively easy with a --client-connect script on the OpenVPN servers. The client connect script is passed the IP address of the new connection. You can then use that to call nsupdate to adjust your DNS records. Here is an ...


1

You need add routes for the destinations you want to route via the VPN tunnel, like this: route add <destip> gw <server IP> Where <destip> is the destination IP you want to route via the VPN, and <server ip>is the IP of the OpenVPN server in the 13.0.9. network. By the way, you should not use publicly routable IP addresses in ...


1

By adding route-nopull to the config file, openvpn would ignore the routes pushed from the server to the client. Something I found on the openvpn site


1

Thanks to kasperd's comment, I learnt that SSH doesn't suffer from TCP-over-TCP since it only moves packet data. I wrote a blog post about it, but the most interesting thing is the netstat output, proving that SSH indeed doesn't preserve Layer 3,4 data: after tunneling, before connecting backslasher@client$ netstat -nap | grep -P '(ssh|redis)' ... tcp ...


1

The local IP address (the IP address that OpenVPN optionally listens on) is the network IP address. So if your office network is 192.168.1.0/24, then you would replace a.b.c.d with an IP address within that subnet range. The subnet for VPN clients is different. It's a private IP address (range) that ONLY OpenVPN and its clients have access to. So if you ...


1

When you set up your VPN connection through the GUI the password is saved in the key-ring. If you save your password in the connection file, like this: sudo nano /etc/NetworkManager/system-connections/MyConnectionExampleName in this file: # 1 here means key-ring I think, but with 0, the password below is used password-flags=0 [vpn-secrets] ...


1

For Debian OS Place your configuration file into /etc/openvpn, for example /etc/openvpn/client.conf. Prefix/comment out lines starting with "down" and "up" (#down and #up) - or delete them (these are calling external script) from client.conf Reload openvpn configuration /etc/init.d/openvpn reload /etc/openvpn/client.conf Check with ifconfig Do you see ...



Only top voted, non community-wiki answers of a minimum length are eligible