Tag Info

New answers tagged

0

After a lot of manpage reading I figured it out: I was missing the iroute directive in the OpenVPN server configuration. After adding these entries to the config it worked: server.ovpn client-config-dir ccd route 192.168.0.0 255.255.255.0 10.8.0.1 ccd\client iroute 192.168.2.0 255.255.255.0


0

I solved the problem on the client side by adding the option mssfix 1300 to the config file. From the openvpn man page: --mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed ...


2

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 ...


0

After quite a search, I found the answer on this blog by Georgie Casey: The no-pull config stays, but after each connection these routes need to be added: ip route add default via {{P-t-P-IP}} dev tun0 table 10 ip rule add from {{tun0-inet addres}} table 10 Those values you can get, for example, from ifconfig (ips modified): tun0 ...


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

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 ...


0

Use the client-to-client directive if you want to allow connectivity between any pair of OpenVPN clients.


-2

client dev tun proto tcp remote 1.2.3.4 1194 resolv-retry infinite nobind persist-key persist-tun verb 1 keepalive 10 900 inactive 3600 comp-lzo <ca> -----BEGIN CERTIFICATE----- .................................... -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- ........................... -----END CERTIFICATE----- ...


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 ...


0

Let's consider following scenario: your VPS has a single ethernet interface, configured with IP address 4.3.2.1/24; your VPS can access the Internet via a default-gateway 4.3.2.254 your VPS has not yet activated any OpenVPN connection; hence there are no tun interface active In such a scenario, from your machine (let's suppose your machine is 9.8.7.6/24 ...


0

This can help: put TCPKeepAlive=yes in your /etc/ssh/sshd_config From man sshd_config | less +/'^ *TCPKeepAlive' TCPKeepAlive Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that ...


0

Found the solution myself, there were two problems: After reading through the openvpn manual the word iroute caught my eye, which was the first and major part of the solution. For details I recommend reading this tutorial https://community.openvpn.net/openvpn/wiki/RoutedLans. After that almost anything worked except connecting to openvpn server and client ...


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 ...


0

Ok i found the answer apparently everything was correct the only STUPID mistake I made was not running the OpenVPN GUI as Administrator => Stupid me


0

The configuration parser is very simple, it expects to see the exact tag string on one line and nothing else. Make sure there is no whitespace before or after the closing tag.


-1

You have to open up the openvpn port (in my case UDP 443). iptables -I INPUT -p udp --dport 443 -j ACCEPT


0

The first problem is that you are testing it on a local network segment 192.168.100.0/24 - it can be done but you run into problems with address conflicts. For example by default you reach the server 192.168.100.200 over the ethernet device but once you set up the VPN you redirect 192.168.100.0/24 into the tunnel with push "route 192.168.100.0 ...


0

Make sure that each computer know the route to the other network. Use route print to validate. Use route add 10.11.0.0 mask 255.255.255.0 10.10.0.1 on B in example, and route add 10.10.0.1 mask 255.255.255.0 10.11.0.1 on A to be sure the packet will go back. Only the machine C that run the openvpn software know all the route.


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] ...


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 ...


0

in H1 try to add a route like this "route add -net 192.168.2.0/24 gw 192.168.1.10" and after that try to ping again, now if you want H1 and H2 ping each other, in H2 do the same, "rout add -net 192.168.1.0/24 gw 192.168.2.10" In this the two pc in the two lans, they will use the vpn client and vpn server to reach the remote lan


0

It is in the man page. It means packets written/read to tun/network: from --verb: 5 -- Output R and W characters to the console for each packet read and write, uppercase is used for TCP/UDP packets and lowercase is used for TUN/TAP packets. 


0

While not relevant to serverfault, the short version is yes. To pass port 88 back to your home server, you will need three rules at least: iptables -t nat -A PREROUTING -p tcp --dport 88 -j DNAT --to <internal VPN address> iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -o tun+ -p tcp --dport 88 -j ACCEPT ...


0

Turns out I was being blind. Edit the VPN connection -> IPv4 Settings -> Click "Routes", and finally check "Use this connection only for resources on its network".


0

Looks like this is a simple matter of sudo. sudo openvpn client.ovpn worked a treat.



Top 50 recent answers are included