Tag Info

Hot answers tagged

9

After extensive study of the openvpn manual, I have found an answer for my question: I you don't want the routes to be executed automatically, but to be handled by your own tool, use the following option: --route-noexec Don't add or remove routes automatically. Instead pass routes to --route-up script using environmental variables. If you ...


5

You would have to have them on unique ports. You can't have two applications listening simultaneously on a single port. So, in your example, because tunnels 1 and 2 both have an end on Site A, those endpoints must have unique ports. Hence the use of ports 1194, and 1195. Now, because the VPN links 1 and 2 are using unique ports 1194 and 1195 on A->B, and ...


5

You have the symptoms of an MTU problem: some TCP connections freeze, more or less reproducibly for a given command or URL but with no easily discernible overall pattern. A telltale symptom is that interactive ssh sessions work well as long as you don't run commands with large output. See Can't access select https sites on Linux over PPPoE for an ...


4

Just wanted to mention that (at least on Ubuntu 12.04) there is --askpass /your/file argument for openvpn, that reads the private key password from a file.


4

You need to do three things on your VPN server (the Linode) to make this work: You must enable IP forwarding: sysctl -w net.ipv4.ip_forward=1 Set up destination NAT (DNAT) to forward the port. You've probably already figured this out because it's standard port forwarding stuff, but for completeness: iptables -t nat -A PREROUTING -d x.x.x.x -p tcp ...


4

I've done something similar with real interfaces, but I can't see why it wouldn't work with VPN interfaces. The idea is that, as you have the same subnet available at different interfaces on that router, it complicates the routing. Basically, when a packet for 10.10.13.123 enters the router, it is DNATed before routing to 192.168.0.123, so you have to be ...


4

You need to tell your router to use your server for this VPN subnet: the correct solution to your problem is to add a route on the router for the OpenVPN subnet. If you can't do this because you can't touch the router, another solution is to setup a NDP proxy for the clients on the eth0 link. As you're using a VPS you probably can't add routes to the ...


3

You can use the down directive in your client configuration to fire off a custom script when the connection drops. In the script, you could do several things for limiting public network connections. Here's my ideas: Setup some iptables that only allow connections to the VPN server, all other connections dropped. Of course, do not forget to remove this ...


3

You should use the new Plugin system. Although there isn't an OpenVPN plugin right now, you can install software within the jail. The jail is not affected on FreeNAS updates. And if you so, you might want to create a plugin and contribute it to the FreeNAS community :-) Further readings: http://doc.freenas.org/index.php/Plugins


3

As penguin359 correctly said, the problem is that the return packets will be routed over the VPN instead of via your local router, which is where the incoming connection came from. SNAT on the router is one solution, but if that's not feasible, you can use advanced routing on your PC. You'll need to add these advanced routing rules in addition to your ...


3

Sat Jul 9 13:14:21 2011 WARNING: potential route subnet conflict between local LAN [192.168.80.0/255.255.255.0] and remote VPN [192.168.80.1/255.255.255.255] For some reason, your configuration seems to be sharing ip address space. Your VPN is selecting addresses from the 192.168.80.x address space, and your local LAN is selecting addresses from the ...


3

How do I ensure that my torrent client actually uses this connection? There is a site, CheckMyTorrentIP, that does exactly that. Basically, you download a torrent file generated specifically for you and once you open it in your client it will report the IP address being used. The IP should be displayed directly in your client but you can also revisit the ...


3

In your server config, "listen localhost" is wrong. That would listen on 127.0.0.1 (or similar), meaning it would not accept connections from outside the box. Your comment next to it doesn't make sense either; and also, you'd normally listen on a public IP. Assuming the above is anonimizing (which you forgot to do in the client config): The ; comments are ...


3

There are two methods to handling this situation. The ideal way by having logrotate notify the process, either via signal or by restarting the process via the postrotate directive. The other way is using the copytruncate. The copytruncate method should work in your situation. Here is the description from the documentation: copytruncate Truncate ...


3

Those are the IP addresses of the local and remote tunnel endpoints (in that order). They're used for routing (and of course the local one is a local IP address, just like on any other interface). You could use public IPs, but its a waste of IP addresses in most cases—you can use internal (RFC1918) addresses even if you're routing a public subnet over the ...


2

My working case with a small correction: nohup openvpn /etc/init.d/ovpn/Userxxx.ovpn & /etc/init.d/ovpn/telnet_commands.sh


2

You can't refuse individual routes, however if you have access to edit your OpenVPN configuration then you can effectively stop the server --pushing any configuration to you by removing all instances of client or pull from your configuration. You will need instead to add tls-client if this directive doesn't already exist in your configuration (client is ...


2

To clarify, while the VPN is running, SSH from external sources is broken, but prior to running the VPN, SSH from all sources was working. The problem comes down to the routing table. As you show above, the default route (0.0.0.0) is going to tun0. I don't understand what's with the funny netmask of 128.0.0.0, but that would cause any external address ...


2

While this is something that is usually done on the server as mentioned in the comments, there might be cases where you only want to use the VPN's DNS for queries inside of the VPN. In that case you'd probably want to run a lightweight DNS daemon on your system and instruct it where to send what query. If you are in several VPNs at once this is basically a ...


2

OpenVPN provides a link. If running in tun (recommended) mode, it provides a link for IP traffic. If running in tap mode, it provides a link for Ethernet traffic (which includes IP, but also all kinds of other things). If you run in tap mode, you need to bridge your OpenVPN tap interface to your Ethernet interface. You can do that with brctl, but, ...


2

First of all: you won't be able to route traffic to 127.x.y.z anywhere other than the local machine (ok, it might even be possible, but you'd certainly break something else in the process...) so I'd recommend updating the apache config to also listen at the VPN IP (e.g. 10.8.0.1). If that's not an option, you could try one of the options at the end of my ...


2

Of course it's possible. The configuration you might want to try is tap rather than tun if you wonder about that, even though it might bit a bit harder to configure, it's easier to get hosts together in one network that way. You might need to enable client-to-client connections for that - there is a line for that commented out in example OpenVPN configs. ...


2

How about workaround to logging into syslog? See usage --daemon [progname] (or --syslog [progname]) in man openvpn (http://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html)


2

You need to modify your iptables rule: It should be for UDP, not for TCP. Additionally, your server gets the UDP traffic to port 2000 as your router rewrites the destination port and IP: iptables -t filter -A INPUT -p udp --dport 2000 -j ACCEPT


2

If you're using NetworkManager you can use the command line tool that's part of it, nmcli to get this list: $ nmcli dev list iface wlan0 | grep IP4 IP4-SETTINGS.ADDRESS: 192.168.1.110 IP4-SETTINGS.PREFIX: 24 (255.255.255.0) IP4-SETTINGS.GATEWAY: 192.168.1.1 IP4-DNS1.DNS: 192.168.1.8 IP4-DNS2.DNS: ...


2

A VPN network usually uses a different interface on your host so you can still use your other interface and public IP. So, you will still be able to access your SSH server as before. The usual implementation used to set up a VPN network is openvpn (clientside and serverside). The whole configuration process is a bit long to be described entirely here and it ...


2

Before you start your VPN take a copy of netstat -rn and ifconfig -a. Start your VPN, and the differences in those two commands will tell you what networks the VPN creates in terms of routes, and what IP you've been assigned to gain visibility of those networks. You will also need to get the IP of the server providing your VPN (or traffic to the VPN server ...


2

I had the same problem and could solve it by removing the line "local xxx.xxx.xxx.xxx." out of the server.conf. via


2

I came across this issue as well. The solution I found was: Enable the EPEL repo (by default in Amazon Linux AMI it's disabled). Install easy-rsa with: yum install easy-rsa -y


2

You might want to run fixfiles -R openvpn restore An ls -alZ should give you something like this (showing your files are in the correct selinux context now): [root@server openvpn]# ls -alZ /etc/openvpn/ drwxr-xr-x. root root system_u:object_r:openvpn_etc_t:s0 . drwxr-xr-x. root root system_u:object_r:etc_t:s0 .. drwxr-xr-x. root root ...



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