Tag Info

New answers tagged

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. openvpn client.ovpn worked a treat.


0

Make sure your bind server is listening on the tunnel interface (should be tun0 in your case).


0

Try this commands: $ mkdir /etc/openvpn/scripts $ mv /etc/openvpn/update-resolv-conf /etc/openvpn/scripts/ $ restorecon -v /etc/openvpn/scripts/ $ restorecon -v /etc/openvpn/scripts/update-resolv-conf $ setsebool openvpn_run_unconfined on $ nano -w /etc/openvpn/config.conf up /etc/openvpn/update-resolv-conf ...


0

Just add an identical route (as the one being pushed to you) to your OpenVPN config, e.g. route 192.168.1.0 netmask 255.255.255.0 net_gateway This will prevent OpenVPN from adding it's own route. Alternatively, use a lower metric value for your route. This way both routes will be created, but the local one will be preferred. P.S. Tested on ...


0

You can bring up your tuntap device together with the vlan interface and bridge afterwards: # The physical network port allow-hotplug eth0 auto eth0 iface eth0 inet manual # The interface used for the bridge auto vlan1 iface vlan1 inet manual vlan_raw_device eth0 pre-up ip tuntap add dev tap0 mode tap user openvpn-system-user ...


0

My problem was here, did not match "auth SHA" server and client: client ...more tls-client tls-auth /storage/emulated/0/OpenVPNkey/ta.key 1 cipher AES-256-CBC auth SHA1 server ...more auth SHA512


0

Because your clean doesn't know, how to reach the other side, you need something like this: vpn client: route add -net 192.168.0.0/24 gw 10.8.0.1 1 #in this way, the client knows, how to reach the other side. remote lan(server side), if i want to reach a pc in the side of my vpn server: route add -net 10.0.0/16 gw "192.168.0.100(local lan ip of my vpn ...


1

Did you try actually looking in the directories to see what was in there, e.g. with ls? It looks like you were randomly pasting commands you copied from the Internet without understanding what they do. And it's very concerning that you don't seem to fully understand what cd does or how to navigate a directory structure; this is something that you really ...


1

compare your configurations with settings in this article and it may help you identify the problems.


1

There is a very similar question at StackOverflow and instruction about how to use multiple CAs (stacked certificates). Another way is to run two OpenVPN instances on the same host, providing them with different ports and certificates signed by different CAs.


0

The best solution I have found based on: 1) Ease of installation on the Server & Client 2) Lots of functionality 3) Good instructions Is http://www.softether.org/ which is an open source solution with lots of security measures and control. This VPS solution allowed HTTP Tunneling too - very easy to implement.


1

It turns out that this was an Amazon issue. I had to disable src/destination checking from the panel to allow it to route packets.


1

So, the right way to use OpenSSL to confirm that you're using the right certificate is: openssl x509 -text -noout -in /root/vpn/server1.crt That will let you confirm that the certificate is indeed the one you think it is, or (as in this case) discover that it isn't.


1

Using the VPN server (being a normal node on your VPN) as a gateway is a client-side issue. You can enable it with redirect-gateway def1 in the client config. Keep in mind that the server has to do proper masquerading (with iptables) for packets being routed from tun0 to the internet and IP forwarding has to be enabled.


0

Finally found the answer. it was the simplest one.I had to search many places to automate the connection process !!! try the following command: echo y | vpnclient.exe connect (Type Profile Name here) user (Type User Name here) pwd (Type Pwd here) nocertpwd stdin if this is not working try the entire path for the exe. For example: echo y | "C:\Program ...


2

It appears that the referenced file does not exist in the current working directory. Is your intention to reference a file that is also in the same directory as the config (.ovpn) file? If so, based on your command line, it does not appear that these files are actually in ./ but rather in configs/. As a better approach, I believe you may want to use the ...


1

If you refer to the OpenVPN man page you will see that --server is sort of an alias/macro directive that performs a bunch of configuration options. You don't have to use --server you could apply the individual configuration directives instead. So if you removed your server line I believe your config would probably be something like this. mode server ...


1

I don't think it's possible. I'm assuming you have something on 192.168.20.1 - 10 that you want on the same subnet. Depending on your situation, you may be able to use a different subnet for OpenVPN and link the two by adding a static route on the 192.168.20 subnet, and using OpenVPN's push and route directives to add a route to the 192.168.20 subnet on the ...


0

Ok, I found the problem. I am running windows server 2012 and turning on IP forwarding was not enough.. I had to enable LAN routing in "Routing and remote access" in server manager by right - clicking "configure and enable routing and remote access" and following the steps in the wizard..


1

How to forward ports in DD-WRT & Tomato with iptables: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/ iptables -I FORWARD -i tun1 -p udp -d {destIP} --dport {port} -j ACCEPT iptables -I FORWARD -i tun1 -p tcp -d {destIP}--dport {port} -j ACCEPT iptables -t nat -I PREROUTING -i tun1 -p udp --dport {port} -j DNAT ...


0

Ok problem solved: The problem was a misconfiguration in libvirt. The virtual bridge was configured in isolated mode, after switching to routed virtual network and adding the route: 10.8.0.0/24 gw 10.10.10.1 to the VM guests everything worked as expected.


0

Turns out I just needed a "rdr" rule right after the nat declaration, to redirect anything coming from an OpenVPN client destined for the server's public IP to the OpenVPN virtual gateway: nat on en0 from ! (en0) to any -> (en0:0) rdr pass on utun0 inet proto { tcp udp } from 10.0.88.0/24 to en0 -> 10.0.88.1 Apparently racoon does this on its own ...


0

I found the solution to the problem with an answer from superuser. The problem is that the server is defaulting to using the tun0 interface rather than eth0, when really we want it to only use tun0 for the private network on 10.8.0.0 to 10.8.0.255. Thus the solution is to configure the client connection to only use the tun0 interface when connecting to other ...


0

Based on the accepted answer to this question, I changed my firewall rule to SNAT instead of MASQUERADE and it worked: -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 60.242.175.133 I added this rule to the /etc/ufw/before.rules file. I did note, however, that if I included "iptables" in the line, UFW failed to reload. Anyway, my clients connecting to ...


0

Ok i got it. @Zoredache pointed me into the right direction. Thank you my friend :) !! Its indeed the case that mount.nfs is trying to point to localhost instead of the vpn ip. You can solve this by using the following mountopts. /sbin/mount.nfs -v 10.0.0.1:/$remotepath /$localpath -o addr=10.0.0.1,clientaddr=10.0.0.6 Debug Output of mount.nfs mount.nfs: ...


0

you are Masquerading / natting 10.8.0.0/24, however the requests are most likely coming from 172.23 subnet - its impossible to say for certain however without more details. You should try natting 172.23.0.0/16 and see if that solves your problem.


0

I've solved using static routing between the server and the public ip that I use to login. ip route add my.local.pc.ip/32 via 192.168.100.10 dev eth1 Best regards


0

The solution was, on the client/router, to do iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o tun1 -j MASQUERADE where tun1 is the VPN interface. By masquerading the internal IPs, everything works.



Top 50 recent answers are included