Tag Info

Hot answers tagged

7

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

This one is the fatal error: Cannot load CA certificate file /home/mak/Downloads/ca.key There are a couple reasons that it may not be able to load the key: Permissions are wrong. Check to make sure the file is readable File doesn't exist. Confirm the path & name is correct. File is in the wrong format, or is not a CA certificate. Try openssl x509 ...


2

Gilles' answer is completely correct, but there is also another potential cause for this. There was a bug in version 2.3.0 of OpenVPN which would disconnect clients when sending large chunks of data: https://community.openvpn.net/openvpn/ticket/263 This issue only occurred when using TCP. UDP was completely unaffected.


2

You shouldn't need to set the ip_forward = 1 unless the interface is acting as a NAT for the other devices, which shouldn't be the case if you've set them up as a bridge. Example Here's my KVM server setup which has a bridge device, br0, with the physical ethernet device, eth0 + all the interfaces for the KVM guests. $ brctl show bridge name bridge id ...


1

Your MySQL server is listening only to localhost (127.0.0.1) so you can't connect to it from other servers. This is a default "safe" setting to prevent other machines from being able to connect to MySQL unless you explicitly allow it. Edit your my.cnf file (probably in /etc/my.cnf) and change the bind-address from 127.0.0.1 to one of: The IP address of ...


1

There is a full list of problems here and you should take the warnings given by OpenVPN serious. But there are just warnings and not the reason for your problem to get a connection. The openvpn plugin of NetworkManager is trying to connect using UDP. I don't know which relation your client.conf has to your actual client configuration. Was it used to import ...


1

First you should change the permissions on your /home/login/client/client.key file so that it is not group or others accessable. chmod 400 /home/login/client/client.key Then as described here you should implement a method to check that your clients connect to the correct server and that no man-in-middle attack is possible.


1

A very basic solution is : 1. use OpenVPN 2.3 or more (currently, the latest is 2.3-alpha) for server + clients 2. use the OpenVPN configuration option below 3. don't use anything else (no ipfilter, no tricks) On the server side, you need to manually distribute VPN addresses (so no server option, you have to use ifconfig or ifconfig-push) : # ...


1

Determine the IP address of your tunnel interface with ifconfig or the ip addr command. Based on your routing table I would expect it to be 192.168.11.1. Additional tunnels would be 192.168.11.5, 192.168.11.9. You should also be able to determine this address from the client's routing table. Try using the IP address of the servers end of the tunnel in ...



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