Hot answers tagged openvpn
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 ...
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
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 ...
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
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
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 ...
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
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 ...
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
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 ...
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
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 ...
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 ...
1
If I understand correctly, you want an OpenVPN tunnel and a PPTP tunnel, each that will route tunneled traffic out eth0, but each with it's own IP.
If I'm wrong in that, try to clarify and I'll do what I can to help. But, I believe this script will do what you're asking for.
#!/bin/bash
# This enables forwarding in the kernel.
echo 1 > ...
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
I just went through getting this working of FreeNAS 8.2 myself. I've got a bunch of notes about the process on my blog at http://joepaetzel.wordpress.com/2012/07/24/openvpn-on-freenas-8-2/
Short version is you need to copy your config files for openvpn to /conf/base/etc/local/etc/openvpn
and
/conf/base/etc/rc.conf
To do that, you need to make the ...
1
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 ...
1
From the OpenVPN manual:
--ifconfig l rn
Set TUN/TAP adapter parameters. l is the IP address of the local VPN endpoint. [...] For TAP devices, rn is the subnet mask of the virtual ethernet segment which is being created or connected to.
[...]
For TAP devices, which provide the ability to create virtual ethernet segments, --ifconfig is used to set ...
1
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 ...
1
At the start of your sample configuration file (that i suggest to copy from /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn-2.0, you have the following:
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
Here you have a great official installation/configuration guide for OpenVPN, that i suggest you step forward with ...
1
The server (the VPN endpoint) must act as a router to forward packets between the local and the VPN network - or rephrased: you got to enable IP forwarding on the server
Either the server announces himself as a router to the local network (if any routing protocol is active) or all clients have to be configured that the server is a gateway to the VPN network ...
1
I found the issue. It was my Firewall. If I disabled the firewall and manually put in the rules I needed with iptables, it works fine. (The #1 issue people have with OpenVPN is usually firewall based according to the #openvpn chatroom on freenode.net). Then I adjusted the firewall scripts to allow my tun0 traffic and restarted it.
1
OpenVPN needs root access because it needs to asign IP addresses to your newly created interface.
If you are running on a graphical mode, you could try NetworkManager plugin for openvpn, which runs pretty well and lets your vpn just one click away. Some users think that NetworkManager is a little bit intrusive (but that is OFT).
Other than that, your best ...
1
If I were faced with this I would:
mv /usr/sbin/openvpn /usr/sbin/openvpn.binary
echo "#!/bin/sh
exec /usr/sbin/openvpn.binary --float $*" >/usr/sbin/openvpn
chmod 755 /usr/sbin/openvpn
and then see if the existing tools still work. It should cause it to pass --float all the time. You can add code to your new 'openvpn.sh' script if you only want ...
1
I'm seeing the same thing (not using vpn) - authrefrsh == calls on the client side. It seems to me like the number of calls increases, then slows down, and the number of authrefrsh then catches up.
Client rpc stats:
calls retrans authrefrsh
261697 0 261697
I see very high iowait too:
dd if=/dev/zero of=/mnt/omoikane/testfile bs=16k ...
Only top voted, non community-wiki answers of a minimum length are eligible
