Answered: Always connecting to Frankfurt or Amsterdam with OpenVPN on Linux

A

adev

New Member
I've been using openvpn on Linux for months with no problem, but suddenly no matter which server I connect to, it ends up connected to Frankfurt or Amsterdam.

I followed the tutorial here: https://www.perfect-privacy.com/howto/openvpn-linux-terminal/ and implemented the fix here: https://board.perfect-privacy.com/threads/openvpn-on-linux-terminal.1510/

When I try to connect to Miami using "sudo openvpn /etc/openvpn/Miami.ovpn" I get the output:

Wed Jun 27 18:02:43 2018 us=821580 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 1 2017
Wed Jun 27 18:02:43 2018 us=821592 library versions: OpenSSL 1.0.2k-fips 26 Jan 2017, LZO 2.08
Wed Jun 27 18:02:43 2018 us=822446 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Wed Jun 27 18:02:43 2018 us=822460 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Jun 27 18:02:43 2018 us=822827 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Jun 27 18:02:43 2018 us=822846 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Jun 27 18:02:43 2018 us=822858 LZO compression initializing
Wed Jun 27 18:02:43 2018 us=822921 Control Channel MTU parms [ L:1626 D:1140 EF:110 EB:0 ET:0 EL:3 ]
Wed Jun 27 18:02:43 2018 us=937290 Data Channel MTU parms [ L:1626 D:1300 EF:126 EB:407 ET:0 EL:3 ]
Wed Jun 27 18:02:43 2018 us=937355 Fragmentation MTU parms [ L:1626 D:1300 EF:125 EB:407 ET:1 EL:3 ]
Wed Jun 27 18:02:43 2018 us=937432 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Wed Jun 27 18:02:43 2018 us=937485 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Wed Jun 27 18:02:43 2018 us=937534 TCP/UDP: Preserving recently used remote address: [AF_INET]38.132.***.***:1149
Wed Jun 27 18:02:43 2018 us=937594 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Jun 27 18:02:43 2018 us=937634 UDP link local: (not bound)
Wed Jun 27 18:02:43 2018 us=937680 UDP link remote: [AF_INET]38.132.***.***:1149
Wed Jun 27 18:02:43 2018 us=965239 TLS: Initial packet from [AF_INET]38.132.***.***:1149, sid=5c239ef5 718378e8
Wed Jun 27 18:02:43 2018 us=965472 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jun 27 18:02:44 2018 us=52399 VERIFY OK: depth=1, C=CH, ST=Zug, L=Zug, O=Perfect Privacy, CN=Perfect Privacy, emailAddress=admin@perfect-privacy.com
Wed Jun 27 18:02:44 2018 us=52799 VERIFY OK: nsCertType=SERVER
Wed Jun 27 18:02:44 2018 us=52857 VERIFY OK: depth=0, C=CH, ST=Zug, O=Perfect Privacy, CN=Server_miami.perfect-privacy.com, emailAddress=admin@perfect-privacy.com
Wed Jun 27 18:02:44 2018 us=284071 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Jun 27 18:02:44 2018 us=284257 [Server_miami.perfect-privacy.com] Peer Connection Initiated with [AF_INET]38.132.***.***:1149
Wed Jun 27 18:02:45 2018 us=528708 SENT CONTROL [Server_miami.perfect-privacy.com]: 'PUSH_REQUEST' (status=1)
Wed Jun 27 18:02:45 2018 us=556080 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,sndbuf 131072,rcvbuf 131072,comp-lzo adaptive,route-gateway 10.3.***.***,redirect-gateway ipv6,route-ipv6 2000::/3,ping 10,ping-restart 60,dhcp-option DNS 38.132.***.***,dhcp-option DNS 78.129.***.***,ifconfig-ipv6 fdbf:****:****:0:56::1240/112 fdbf:****:****:0:56::1,ifconfig 10.3.***.*** 255.255.255.0,peer-id 0'
Wed Jun 27 18:02:45 2018 us=556248 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jun 27 18:02:45 2018 us=556297 OPTIONS IMPORT: compression parms modified
Wed Jun 27 18:02:45 2018 us=556363 LZO compression initializing
Wed Jun 27 18:02:45 2018 us=556420 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Wed Jun 27 18:02:45 2018 us=556468 Socket Buffers: R=[212***->262***] S=[212***->262***]
Wed Jun 27 18:02:45 2018 us=556511 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jun 27 18:02:45 2018 us=556550 OPTIONS IMPORT: route options modified
Wed Jun 27 18:02:45 2018 us=556590 OPTIONS IMPORT: route-related options modified
Wed Jun 27 18:02:45 2018 us=556629 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Jun 27 18:02:45 2018 us=556662 OPTIONS IMPORT: peer-id set
Wed Jun 27 18:02:45 2018 us=556686 OPTIONS IMPORT: adjusting link_mtu to 1629
Wed Jun 27 18:02:45 2018 us=556717 Data Channel MTU parms [ L:1609 D:1300 EF:109 EB:407 ET:0 EL:3 ]
Wed Jun 27 18:02:45 2018 us=556810 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Jun 27 18:02:45 2018 us=556843 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Jun 27 18:02:45 2018 us=556872 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Jun 27 18:02:45 2018 us=556900 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Jun 27 18:02:45 2018 us=557066 ROUTE_GATEWAY 10.0.0.1/255.255.255.0 IFACE=eth0 HWADDR=0e:9c:d1:2a:7c:d2
Wed Jun 27 18:02:45 2018 us=557109 GDG6: remote_host_ipv6=n/a
Wed Jun 27 18:02:45 2018 us=557159 GDG6: NLMSG_ERROR: error No route to host

Wed Jun 27 18:02:45 2018 us=557205 ROUTE6: default_gateway=UNDEF
Wed Jun 27 18:02:45 2018 us=563998 TUN/TAP device tun0 opened
Wed Jun 27 18:02:45 2018 us=564024 TUN/TAP TX queue length set to 100
Wed Jun 27 18:02:45 2018 us=564036 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Wed Jun 27 18:02:45 2018 us=564051 /sbin/ip link set dev tun0 up mtu 1500
Wed Jun 27 18:02:45 2018 us=565686 /sbin/ip addr add dev tun0 10.3.***.***/24 broadcast 10.3.***.***
Wed Jun 27 18:02:45 2018 us=566474 /sbin/ip -6 addr add fdbf:****:****:0:56::1240/112 dev tun0
Wed Jun 27 18:02:45 2018 us=568210 /etc/openvpn/client.up tun0 1500 1609 10.3.***.*** 255.255.255.0 init
Wed Jun 27 18:02:47 2018 us=825396 /sbin/ip route add 38.132.***.***/32 via 10.0.0.1
Wed Jun 27 18:02:47 2018 us=826342 /sbin/ip route add 0.0.0.0/1 via 10.3.***.***
Wed Jun 27 18:02:47 2018 us=827075 /sbin/ip route add 128.0.0.0/1 via 10.3.***.***
Wed Jun 27 18:02:47 2018 us=827722 add_route_ipv6(2000::/3 -> fdbf:****:****:0:56::1 metric -1) dev tun0
Wed Jun 27 18:02:47 2018 us=827746 /sbin/ip -6 route add 2000::/3 dev tun0
Wed Jun 27 18:02:47 2018 us=828463 add_route_ipv6:):/3 -> fdbf:****:****:0:56::1 metric -1) dev tun0
Wed Jun 27 18:02:47 2018 us=828497 /sbin/ip -6 route add ::/3 dev tun0
Wed Jun 27 18:02:47 2018 us=829082 add_route_ipv6(2000::/4 -> fdbf:****:****:0:56::1 metric -1) dev tun0
Wed Jun 27 18:02:47 2018 us=829101 /sbin/ip -6 route add 2000::/4 dev tun0
Wed Jun 27 18:02:47 2018 us=829745 add_route_ipv6(3000::/4 -> fdbf:****:****:0:56::1 metric -1) dev tun0
Wed Jun 27 18:02:47 2018 us=829778 /sbin/ip -6 route add 3000::/4 dev tun0
Wed Jun 27 18:02:47 2018 us=830442 add_route_ipv6(fc00::/7 -> fdbf:****:****:0:56::1 metric -1) dev tun0
Wed Jun 27 18:02:47 2018 us=830463 /sbin/ip -6 route add fc00::/7 dev tun0
Wed Jun 27 18:02:47 2018 us=831124 Initialization Sequence Completed​

If I run "wget -q -O - https://checkip.perfect-privacy.com/csv" I get the output:

IP,DNS,VPN,TOR,COUNTRY,CITY
95.211.**.***,amsterdam2.perfect-privacy.com,true,false,Netherlands,Amsterdam​

I do see some issues with ipv6 here, but I still don't understand why this would result in a successful connection to a server in Amsterdam?
 
Solution
PP Lars
Hi,

If you use neurorouting you see Amsterdam or Frankfurt because thats where our checkip servers are located. Neurorouting brings you to the nearest exit.
Google "check my ip" and visit some other checkip sites, you will always see a different location depending on where the checkip site is located.

Regards
Lars
Sort by date Sort by votes
Hi,

If you use neurorouting you see Amsterdam or Frankfurt because thats where our checkip servers are located. Neurorouting brings you to the nearest exit.
Google "check my ip" and visit some other checkip sites, you will always see a different location depending on where the checkip site is located.

Regards
Lars
 
Upvote 0 Downvote
Solution
You must log in or register to reply here.
Back
Top