Hello, Well, it seems that my problem is quite a common one but after seeking several similar topics I couldn't find a solution that must be trivial. I have an OpenVPN server installed on a VPS hosted by OVH with Ubuntu 14.04 server on it. When I try to connect my Windows 8.1 client on it, I can access internet with OpenVPN GUI no admin mode, but it doesn't seem to do anything, even websites like http://www.whatismyip.com/ still show my usual IP adress. It becomes interesting when I try to run OpenVPN GUI on admin mode, because... I can't access internet at all. Every single page is stuck on the hostname resolution and then Chrome tells me I'm not connected to Internet at all. Here is my server.conf file : [code]#Serveur TCP/443 mode server proto tcp port 443 dev tun # Cles et certificats ca ca.crt cert server.crt key server.key dh dh2048.pem tls-auth ta.key 0 cipher AES-256-CBC # Reseau server 10.8.0.0 255.255.255.0 push "route 10.8.0.0 255.255.255.0" push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.4.4" push "dhcp-option DNS 8.8.8.8" keepalive 10 120 # Securite user nobody group nogroup chroot /etc/openvpn/jail persist-key persist-tun comp-lzo # Log verb 3 mute 20 status openvpn-status.log log-append /var/log/openvpn.log [/code] And my client.conf : [code]# Client client dev tun proto tcp-client remote 92.222.5.180 443 resolv-retry infinite cipher AES-256-CBC # Cles ca ca.crt cert gyoo.crt key gyoo.key tls-auth ta.key 1 # Securite nobind persist-key persist-tun comp-lzo verb 3 [/code] My logfile when I connect OpenVPN, admin mode : [quote]Sun Jan 18 11:06:50 2015 OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 1 2014 Sun Jan 18 11:06:50 2015 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08 Sun Jan 18 11:06:50 2015 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 Sun Jan 18 11:06:50 2015 Need hold release from management interface, waiting... Sun Jan 18 11:06:50 2015 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 Sun Jan 18 11:06:50 2015 MANAGEMENT: CMD 'state on' Sun Jan 18 11:06:50 2015 MANAGEMENT: CMD 'log all on' Sun Jan 18 11:06:50 2015 MANAGEMENT: CMD 'hold off' Sun Jan 18 11:06:50 2015 MANAGEMENT: CMD 'hold release' Sun Jan 18 11:06:50 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Sun Jan 18 11:06:50 2015 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Sun Jan 18 11:06:50 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Jan 18 11:06:50 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Jan 18 11:06:50 2015 Socket Buffers: R=[65536->65536] S=[65536->65536] Sun Jan 18 11:06:50 2015 Attempting to establish TCP connection with [AF_INET]92.222.5.180:443 [nonblock] Sun Jan 18 11:06:50 2015 MANAGEMENT: >STATE:1421575610,TCP_CONNECT,,, Sun Jan 18 11:06:51 2015 TCP connection established with [AF_INET]92.222.5.180:443 Sun Jan 18 11:06:51 2015 TCPv4_CLIENT link local: [undef] Sun Jan 18 11:06:51 2015 TCPv4_CLIENT link remote: [AF_INET]92.222.5.180:443 Sun Jan 18 11:06:51 2015 MANAGEMENT: >STATE:1421575611,WAIT,,, Sun Jan 18 11:06:52 2015 MANAGEMENT: >STATE:1421575612,AUTH,,, Sun Jan 18 11:06:52 2015 TLS: Initial packet from [AF_INET]92.222.5.180:443, sid=f133503b e6071353 Sun Jan 18 11:06:53 2015 VERIFY OK: depth=1, C=FR, ST=92, L=BourgLaReine, O=Gyoo, OU=Gyoo, CN=Gyoo CA, name=EasyRSA, emailAddress=gyozell@gmail.com Sun Jan 18 11:06:53 2015 VERIFY OK: depth=0, C=FR, ST=92, L=BourgLaReine, O=Gyoo, OU=Gyoo, CN=server, name=EasyRSA, emailAddress=gyozell@gmail.com Sun Jan 18 11:06:54 2015 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Sun Jan 18 11:06:54 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Jan 18 11:06:54 2015 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Sun Jan 18 11:06:54 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sun Jan 18 11:06:54 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Sun Jan 18 11:06:54 2015 [server] Peer Connection Initiated with [AF_INET]92.222.5.180:443 Sun Jan 18 11:06:56 2015 MANAGEMENT: >STATE:1421575616,GET_CONFIG,,, Sun Jan 18 11:06:57 2015 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Sun Jan 18 11:06:57 2015 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.4.4,dhcp-option DNS 8.8.8.8,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' Sun Jan 18 11:06:57 2015 OPTIONS IMPORT: timers and/or timeouts modified Sun Jan 18 11:06:57 2015 OPTIONS IMPORT: --ifconfig/up options modified Sun Jan 18 11:06:57 2015 OPTIONS IMPORT: route options modified Sun Jan 18 11:06:57 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Sun Jan 18 11:06:57 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Sun Jan 18 11:06:57 2015 MANAGEMENT: >STATE:1421575617,ASSIGN_IP,,10.8.0.6, Sun Jan 18 11:06:57 2015 open_tun, tt->ipv6=0 Sun Jan 18 11:06:57 2015 TAP-WIN32 device [FrozenWay] opened: \\.\Global\{E9FCE9F8-1EA8-490A-94BD-406673F62CA0}.tap Sun Jan 18 11:06:57 2015 TAP-Windows Driver Version 9.9 Sun Jan 18 11:06:57 2015 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {E9FCE9F8-1EA8-490A-94BD-406673F62CA0} [DHCP-serv: 10.8.0.5, lease-time: 31536000] Sun Jan 18 11:06:57 2015 Successful ARP Flush on interface [9] {E9FCE9F8-1EA8-490A-94BD-406673F62CA0} Sun Jan 18 11:07:02 2015 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up Sun Jan 18 11:07:02 2015 C:\WINDOWS\system32\route.exe ADD 92.222.5.180 MASK 255.255.255.255 192.168.1.254 Sun Jan 18 11:07:02 2015 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4 Sun Jan 18 11:07:02 2015 Route addition via IPAPI succeeded [adaptive] Sun Jan 18 11:07:02 2015 C:\WINDOWS\system32\route.exe ADD 192.168.1.254 MASK 255.255.255.255 192.168.1.254 IF 20 Sun Jan 18 11:07:02 2015 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4 Sun Jan 18 11:07:02 2015 Route addition via IPAPI succeeded [adaptive] Sun Jan 18 11:07:02 2015 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.5 Sun Jan 18 11:07:02 2015 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 Sun Jan 18 11:07:02 2015 Route addition via IPAPI succeeded [adaptive] Sun Jan 18 11:07:02 2015 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.5 Sun Jan 18 11:07:02 2015 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 Sun Jan 18 11:07:02 2015 Route addition via IPAPI succeeded [adaptive] Sun Jan 18 11:07:02 2015 MANAGEMENT: >STATE:1421575622,ADD_ROUTES,,, Sun Jan 18 11:07:02 2015 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.5 Sun Jan 18 11:07:02 2015 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 Sun Jan 18 11:07:02 2015 Route addition via IPAPI succeeded [adaptive] Sun Jan 18 11:07:02 2015 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5 Sun Jan 18 11:07:02 2015 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 Sun Jan 18 11:07:02 2015 Route addition via IPAPI succeeded [adaptive] Sun Jan 18 11:07:02 2015 Initialization Sequence Completed Sun Jan 18 11:07:02 2015 MANAGEMENT: >STATE:1421575622,CONNECTED,SUCCESS,10.8.0.6,92.222.5.180[/quote] If you need anything else, I'll be glad to answer. If you also need anything related to linux (I know the basics only), if you could add a few commands so I can do it without looking for the right thing for hours, that'd be very nice of you :) Best regards, Gyoo.

2 things, 1)post your nat rule used on your openvpn server 2)is your VPS a VZ container? Michael.

[quote="Gyoo"]When I try to connect my Windows 8.1 client on it, I can access internet with OpenVPN GUI [u]no admin mode[/u][/quote]yu can connect to the internet because your VPN connection has failed as OpenVPN requires administrator access to modify routing table .. [quote="Gyoo"]It becomes interesting when I try to run OpenVPN GUI [u]on admin mode[/u], because... I can't access internet at all[/quote]The client log shows a successful connection .. so have you enabled [url=https://community.openvpn.net/openvpn/wiki/265-how-do-i-enable-ip-forwarding]IP_Forwardiing[/url] on the server ?

Hi, sorry for the late reply to your questions :/ [quote]1)post your nat rule used on your openvpn server[/quote] >iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 10.8.0.0/24 anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination [quote]2)is your VPS a VZ container?[/quote] I don't see anything related to OpenVZ on my server, neither on the OVH interface. [quote]The client log shows a successful connection .. so have you enabled IP_Forwardiing on the server ?[/quote] Yes I did

please post the output of: tracert 8.8.8.8 on your client after the vpn is up. Michael.

[img]http://puu.sh/fbaJ7/bb6405db4e.png[/img] Even if it's in french I guess you can see what's going on here. The weird thing is, some other services work well, like IRC and skype... it's really just the internet browser it seems.

please post the output of: ifconfig iptables -L -v on your openvpn server and please post the exact NAT rule you used. Michael.

[quote="ifconfig"] ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:15023 errors:0 dropped:0 overruns:0 frame:0 TX packets:15023 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1819530 (1.8 MB) TX bytes:1819530 (1.8 MB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2322 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:350825 (350.8 KB) TX bytes:678 (678.0 B) venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.0.2 P-t-P:127.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.255 inet6 addr: 2001:41d0:52:a00::870/56 Scope:Global UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:2447338 errors:0 dropped:0 overruns:0 frame:0 TX packets:2315858 errors:0 dropped:10125 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:286791780 (286.7 MB) TX bytes:186837699 (186.8 MB) venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:92.222.5.180 P-t-P:92.222.5.180 Bcast:92.222.5.255 Mask:255.255.255.0 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 [/quote] [quote="iptables -L -v"] Chain INPUT (policy ACCEPT 727 packets, 58054 bytes) pkts bytes target prot opt in out source destination 62958 6225K fail2ban-ssh tcp -- any any anywhere anywhere multiport dports ssh Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 734 packets, 75000 bytes) pkts bytes target prot opt in out source destination Chain fail2ban-ssh (1 references) pkts bytes target prot opt in out source destination 48269 5155K RETURN all -- any any anywhere anywhere [/quote] I used the following command when configuring my NAT : iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

now we getting somewhere... [quote]venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:92.222.5.180 P-t-P:92.222.5.180 Bcast:92.222.5.255 Mask:255.255.255.0[/quote] your server probably IS VZ container, because of that your NAT rule is wrong for 2 reasons, 1)you should use venet0:0 as output interface (instead of eth0) 2)the NAT rule for vz based servers is different, with that in mind please issue: [code]iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0:0 -j SNAT --to-source 92.222.5.180[/code] Michael.

verify your rule by issuing iptables -t nat -L -v also run a tracert 8.8.8.8 from your client and post the output here. Michael.

Can't access internet with my VPN (Admin mode W8.1)

Gyoo

14:54:57.029032 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 9, length 40
14:55:01.653242 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 10, length 40
14:55:06.168047 IP 5.39.111.9 > 92.222.5.180: ICMP echo request, id 30068, seq 156, length 64
14:55:06.168361 IP 92.222.5.180 > 5.39.111.9: ICMP echo reply, id 30068, seq 156, length 64
14:55:06.186482 IP 37.187.65.250 > 92.222.5.180: ICMP echo request, id 30094, seq 179, length 76
14:55:06.186600 IP 92.222.5.180 > 37.187.65.250: ICMP echo reply, id 30094, seq 179, length 76
14:55:06.650954 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 11, length 40
14:55:06.856537 IP 92.222.5.180 > 117.253.96.216: ICMP 92.222.5.180 tcp port 22 unreachable, length 244
14:55:11.654593 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 12, length 40
14:55:12.289383 IP 5.39.111.9 > 92.222.5.180: ICMP echo request, id 30068, seq 400, length 64
14:55:12.289492 IP 92.222.5.180 > 5.39.111.9: ICMP echo reply, id 30068, seq 400, length 64
14:55:23.915946 IP 5.39.111.9 > 92.222.5.180: ICMP echo request, id 30275, seq 156, length 64
14:55:23.916041 IP 92.222.5.180 > 5.39.111.9: ICMP echo reply, id 30275, seq 156, length 64

Here is what I got once the ping 8.8.8.8 has started

Meanwhile, the stats for the ping I did on the client are 4 packets sent, 100% loss.

Traffic

maikcat wrote2)the NAT rule for vz based servers is different,

with that in mind please issue:

Code:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0:0 -j SNAT --to-source 92.222.5.180

Gyoo wrote14:54:57.029032 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 9, length 40

Your NAT rule is not working ..

Gyoo wrote14:55:06.168047 IP 5.39.111.9 > 92.222.5.180: ICMP echo request, id 30068, seq 156, length 64
14:55:06.168361 IP 92.222.5.180 > 5.39.111.9: ICMP echo reply, id 30068, seq 156, length 64

This is very confused .. are you pinging your server from somewhere else ?

Who is: 5.39.111.9

Gyoo wrotevenet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:92.222.5.180 P-t-P:92.222.5.180 Bcast:92.222.5.255 Mask:255.255.255.0

Has this IP address changed ?

Gyoo

Traffic wrote
maikcat wrote2)the NAT rule for vz based servers is different,

with that in mind please issue:

Code:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0:0 -j SNAT --to-source 92.222.5.180
Gyoo wrote14:54:57.029032 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 9, length 40
Your NAT rule is not working ..

Apparently it has been removed, probably after I restarted my server a few days ago. Whoops.
I just installed iptables-permanent to solve this issue for next times.

Anyway, I retried a ping after putting the rules again, the result is the same :

17:50:16.852915 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 111, length 40
17:50:21.853165 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 112, length 40

I noticed that you're specifying port 24 for this rule... can't the problem come from that ?

Gyoo wrote14:55:06.168047 IP 5.39.111.9 > 92.222.5.180: ICMP echo request, id 30068, seq 156, length 64
14:55:06.168361 IP 92.222.5.180 > 5.39.111.9: ICMP echo reply, id 30068, seq 156, length 64
This is very confused .. are you pinging your server from somewhere else ?

Who is: 5.39.111.9

Gyoo wrotevenet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:92.222.5.180 P-t-P:92.222.5.180 Bcast:92.222.5.255 Mask:255.255.255.0
Has this IP address changed ?

5.39.111.9 seems to be located in a datacenter of OVH. This ping must come from them to track the uptime of the server, or something like that.
And the adress for venet0:0 has not changed.

maikcat

can you post again your CURRENT iptable rules by using

iptables -L -v
iptables -L -t nat -v

also for testing leave chroot aside please..

also deactivate any apparmour/selinux rules if any.

Michael.

Gyoo

iptables -L -t nat -v wroteChain PREROUTING (policy ACCEPT 1 packets, 118 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- any venet0:0 10.8.0.0/24 anywhere to:92.222.5.180

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

iptables -L -v wroteChain INPUT (policy ACCEPT 1011 packets, 85450 bytes)
pkts bytes target prot opt in out source destination
50658 3854K fail2ban-ssh tcp -- any any anywhere anywhere multiport dports ssh

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 880 packets, 105K bytes)
pkts bytes target prot opt in out source destination

Chain fail2ban-ssh (1 references)
pkts bytes target prot opt in out source destination
45884 3409K RETURN all -- any any anywhere anywhere

And for the chroot thing... I'd be pleased to do it but I honestly don't know how :/ I don't want to make any mistake either :x

Traffic

maikcat wrotealso for testing leave chroot aside please..

Gyoo wroteAnd for the chroot thing... I'd be pleased to do it but I honestly don't know how :/

Gyoo wroteHere is my server.conf file :

Code:
#Serveur TCP/443
...
chroot /etc/openvpn/jail

Gyoo

I'm feeling dumb... anyway, commented that line, still no change though 🙁

Traffic

Traffic wroteI suggest:

On your server:
Code:
tcpdump -n -i venet0:0 icmp
then ping 8.8.8.8 from the client.

Gyoo wroteAnyway, I retried a ping after putting the rules again, the result is the same :

17:50:16.852915 IP 10.8.0.6 > 8.8.8.8: ICMP echo request, id 1, seq 111, length 40

This: 10.8.0.6 should be this: 92.222.5.180 .: Your NAT is not working ..

Gyoo

I will contact OVH again to see what's going on with my nat rules then.

Thanks for your help still 🙂

« Previous Page