Connected to VPN, can't ssh into server

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
-1
down vote

favorite
1












I connect to my universities VPN network with openvpn with it's configuration file provided by the university.



client
remote 141.52.8.20
port 1194
dev tun
proto udp
auth-user-pass
nobind
comp-lzo no
tls-version-min 1.2
ca /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
verify-x509-name "C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu" subject
cipher AES-256-CBC
auth SHA384
verb 3
script-security 2


The output of the connection is:



Mon Apr 2 12:30:11 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Apr 2 12:30:11 2018 UDP link local: (not bound)
Mon Apr 2 12:30:11 2018 UDP link remote: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 TLS: Initial packet from [AF_INET]141.52.8.20:1194, sid=9b21388b f279b997
Mon Apr 2 12:30:11 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=3, C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=2, C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Certification Authority 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=1, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, CN=KIT-CA
Mon Apr 2 12:30:11 2018 VERIFY X509NAME OK: C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=0, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 Control Channel: TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Mon Apr 2 12:30:11 2018 [ovpn.scc.kit.edu] Peer Connection Initiated with [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:12 2018 SENT CONTROL [ovpn.scc.kit.edu]: 'PUSH_REQUEST' (status=1)
Mon Apr 2 12:30:12 2018 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72,dhcp-option DOMAIN kit.edu,tun-ipv6,route-gateway 141.52.120.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 2a00:1398:8:203::10e8/64 2a00:1398:8:203::1,ifconfig 141.52.120.234 255.255.255.0,peer-id 56,cipher AES-256-GCM'
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: timers and/or timeouts modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ifconfig/up options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route-related options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: peer-id set
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: data channel crypto options modified
Mon Apr 2 12:30:12 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Apr 2 12:30:12 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=enp30s0 HWADDR=b0:6e:bf:d3:02:68
Mon Apr 2 12:30:12 2018 GDG6: remote_host_ipv6=n/a
Mon Apr 2 12:30:12 2018 ROUTE6_GATEWAY fe80::e228:6dff:fecd:a276 IFACE=enp30s0
Mon Apr 2 12:30:12 2018 TUN/TAP device tun0 opened
Mon Apr 2 12:30:12 2018 TUN/TAP TX queue length set to 100
Mon Apr 2 12:30:12 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mon Apr 2 12:30:12 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Mon Apr 2 12:30:12 2018 /usr/bin/ip addr add dev tun0 141.52.120.234/24 broadcast 141.52.120.255
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 addr add 2a00:1398:8:203::10e8/64 dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 141.52.8.20/32 via 192.168.178.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 0.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 128.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 add_route_ipv6(2000::/3 -> 2a00:1398:8:203::1 metric -1) dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 route add 2000::/3 dev tun0
Mon Apr 2 12:30:12 2018 Initialization Sequence Completed


So it seems the connection is working. Yet I can't ssh into any of the servers. I always get the error



ssh: Could not resolve hostname server.blabla.de: Name of service not known


Yet internet works perfectly (Does the internet use the vpn? How do I check this?)



How can I even debug this? I don't really know where to start.







share|improve this question






















  • Is "server.blabla.de" globally resolvable? Does dig server.blabla.de differ from dig @141.3.175.71 server.blabla.de? The server name you are requesting to may be only available through private nameservers, which are supplied by the OpenVPN server dhcp-option DNS parameters
    – Torin Carey
    Apr 2 at 14:25










  • @TorinCarey If I understand what you mean, then no. "server.blabla.de" can only be resolved any way if you are in the intranet. I am dualbooting and have no problem connecting to the servers in Windows 10.
    – Fl.pf.
    Apr 3 at 11:14














up vote
-1
down vote

favorite
1












I connect to my universities VPN network with openvpn with it's configuration file provided by the university.



client
remote 141.52.8.20
port 1194
dev tun
proto udp
auth-user-pass
nobind
comp-lzo no
tls-version-min 1.2
ca /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
verify-x509-name "C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu" subject
cipher AES-256-CBC
auth SHA384
verb 3
script-security 2


The output of the connection is:



Mon Apr 2 12:30:11 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Apr 2 12:30:11 2018 UDP link local: (not bound)
Mon Apr 2 12:30:11 2018 UDP link remote: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 TLS: Initial packet from [AF_INET]141.52.8.20:1194, sid=9b21388b f279b997
Mon Apr 2 12:30:11 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=3, C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=2, C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Certification Authority 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=1, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, CN=KIT-CA
Mon Apr 2 12:30:11 2018 VERIFY X509NAME OK: C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=0, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 Control Channel: TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Mon Apr 2 12:30:11 2018 [ovpn.scc.kit.edu] Peer Connection Initiated with [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:12 2018 SENT CONTROL [ovpn.scc.kit.edu]: 'PUSH_REQUEST' (status=1)
Mon Apr 2 12:30:12 2018 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72,dhcp-option DOMAIN kit.edu,tun-ipv6,route-gateway 141.52.120.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 2a00:1398:8:203::10e8/64 2a00:1398:8:203::1,ifconfig 141.52.120.234 255.255.255.0,peer-id 56,cipher AES-256-GCM'
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: timers and/or timeouts modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ifconfig/up options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route-related options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: peer-id set
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: data channel crypto options modified
Mon Apr 2 12:30:12 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Apr 2 12:30:12 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=enp30s0 HWADDR=b0:6e:bf:d3:02:68
Mon Apr 2 12:30:12 2018 GDG6: remote_host_ipv6=n/a
Mon Apr 2 12:30:12 2018 ROUTE6_GATEWAY fe80::e228:6dff:fecd:a276 IFACE=enp30s0
Mon Apr 2 12:30:12 2018 TUN/TAP device tun0 opened
Mon Apr 2 12:30:12 2018 TUN/TAP TX queue length set to 100
Mon Apr 2 12:30:12 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mon Apr 2 12:30:12 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Mon Apr 2 12:30:12 2018 /usr/bin/ip addr add dev tun0 141.52.120.234/24 broadcast 141.52.120.255
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 addr add 2a00:1398:8:203::10e8/64 dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 141.52.8.20/32 via 192.168.178.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 0.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 128.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 add_route_ipv6(2000::/3 -> 2a00:1398:8:203::1 metric -1) dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 route add 2000::/3 dev tun0
Mon Apr 2 12:30:12 2018 Initialization Sequence Completed


So it seems the connection is working. Yet I can't ssh into any of the servers. I always get the error



ssh: Could not resolve hostname server.blabla.de: Name of service not known


Yet internet works perfectly (Does the internet use the vpn? How do I check this?)



How can I even debug this? I don't really know where to start.







share|improve this question






















  • Is "server.blabla.de" globally resolvable? Does dig server.blabla.de differ from dig @141.3.175.71 server.blabla.de? The server name you are requesting to may be only available through private nameservers, which are supplied by the OpenVPN server dhcp-option DNS parameters
    – Torin Carey
    Apr 2 at 14:25










  • @TorinCarey If I understand what you mean, then no. "server.blabla.de" can only be resolved any way if you are in the intranet. I am dualbooting and have no problem connecting to the servers in Windows 10.
    – Fl.pf.
    Apr 3 at 11:14












up vote
-1
down vote

favorite
1









up vote
-1
down vote

favorite
1






1





I connect to my universities VPN network with openvpn with it's configuration file provided by the university.



client
remote 141.52.8.20
port 1194
dev tun
proto udp
auth-user-pass
nobind
comp-lzo no
tls-version-min 1.2
ca /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
verify-x509-name "C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu" subject
cipher AES-256-CBC
auth SHA384
verb 3
script-security 2


The output of the connection is:



Mon Apr 2 12:30:11 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Apr 2 12:30:11 2018 UDP link local: (not bound)
Mon Apr 2 12:30:11 2018 UDP link remote: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 TLS: Initial packet from [AF_INET]141.52.8.20:1194, sid=9b21388b f279b997
Mon Apr 2 12:30:11 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=3, C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=2, C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Certification Authority 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=1, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, CN=KIT-CA
Mon Apr 2 12:30:11 2018 VERIFY X509NAME OK: C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=0, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 Control Channel: TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Mon Apr 2 12:30:11 2018 [ovpn.scc.kit.edu] Peer Connection Initiated with [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:12 2018 SENT CONTROL [ovpn.scc.kit.edu]: 'PUSH_REQUEST' (status=1)
Mon Apr 2 12:30:12 2018 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72,dhcp-option DOMAIN kit.edu,tun-ipv6,route-gateway 141.52.120.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 2a00:1398:8:203::10e8/64 2a00:1398:8:203::1,ifconfig 141.52.120.234 255.255.255.0,peer-id 56,cipher AES-256-GCM'
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: timers and/or timeouts modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ifconfig/up options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route-related options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: peer-id set
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: data channel crypto options modified
Mon Apr 2 12:30:12 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Apr 2 12:30:12 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=enp30s0 HWADDR=b0:6e:bf:d3:02:68
Mon Apr 2 12:30:12 2018 GDG6: remote_host_ipv6=n/a
Mon Apr 2 12:30:12 2018 ROUTE6_GATEWAY fe80::e228:6dff:fecd:a276 IFACE=enp30s0
Mon Apr 2 12:30:12 2018 TUN/TAP device tun0 opened
Mon Apr 2 12:30:12 2018 TUN/TAP TX queue length set to 100
Mon Apr 2 12:30:12 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mon Apr 2 12:30:12 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Mon Apr 2 12:30:12 2018 /usr/bin/ip addr add dev tun0 141.52.120.234/24 broadcast 141.52.120.255
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 addr add 2a00:1398:8:203::10e8/64 dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 141.52.8.20/32 via 192.168.178.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 0.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 128.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 add_route_ipv6(2000::/3 -> 2a00:1398:8:203::1 metric -1) dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 route add 2000::/3 dev tun0
Mon Apr 2 12:30:12 2018 Initialization Sequence Completed


So it seems the connection is working. Yet I can't ssh into any of the servers. I always get the error



ssh: Could not resolve hostname server.blabla.de: Name of service not known


Yet internet works perfectly (Does the internet use the vpn? How do I check this?)



How can I even debug this? I don't really know where to start.







share|improve this question














I connect to my universities VPN network with openvpn with it's configuration file provided by the university.



client
remote 141.52.8.20
port 1194
dev tun
proto udp
auth-user-pass
nobind
comp-lzo no
tls-version-min 1.2
ca /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
verify-x509-name "C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu" subject
cipher AES-256-CBC
auth SHA384
verb 3
script-security 2


The output of the connection is:



Mon Apr 2 12:30:11 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Apr 2 12:30:11 2018 UDP link local: (not bound)
Mon Apr 2 12:30:11 2018 UDP link remote: [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:11 2018 TLS: Initial packet from [AF_INET]141.52.8.20:1194, sid=9b21388b f279b997
Mon Apr 2 12:30:11 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=3, C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=2, C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Certification Authority 2
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=1, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, CN=KIT-CA
Mon Apr 2 12:30:11 2018 VERIFY X509NAME OK: C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 VERIFY OK: depth=0, C=DE, ST=Baden-Wuerttemberg, L=Karlsruhe, O=Karlsruhe Institute of Technology, OU=Steinbuch Centre for Computing, CN=ovpn.scc.kit.edu
Mon Apr 2 12:30:11 2018 Control Channel: TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Mon Apr 2 12:30:11 2018 [ovpn.scc.kit.edu] Peer Connection Initiated with [AF_INET]141.52.8.20:1194
Mon Apr 2 12:30:12 2018 SENT CONTROL [ovpn.scc.kit.edu]: 'PUSH_REQUEST' (status=1)
Mon Apr 2 12:30:12 2018 PUSH: Received control message: 'PUSH_REPLY,topology subnet,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72,dhcp-option DOMAIN kit.edu,tun-ipv6,route-gateway 141.52.120.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 2a00:1398:8:203::10e8/64 2a00:1398:8:203::1,ifconfig 141.52.120.234 255.255.255.0,peer-id 56,cipher AES-256-GCM'
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: timers and/or timeouts modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ifconfig/up options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: route-related options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: peer-id set
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Mon Apr 2 12:30:12 2018 OPTIONS IMPORT: data channel crypto options modified
Mon Apr 2 12:30:12 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Apr 2 12:30:12 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Apr 2 12:30:12 2018 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=enp30s0 HWADDR=b0:6e:bf:d3:02:68
Mon Apr 2 12:30:12 2018 GDG6: remote_host_ipv6=n/a
Mon Apr 2 12:30:12 2018 ROUTE6_GATEWAY fe80::e228:6dff:fecd:a276 IFACE=enp30s0
Mon Apr 2 12:30:12 2018 TUN/TAP device tun0 opened
Mon Apr 2 12:30:12 2018 TUN/TAP TX queue length set to 100
Mon Apr 2 12:30:12 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mon Apr 2 12:30:12 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Mon Apr 2 12:30:12 2018 /usr/bin/ip addr add dev tun0 141.52.120.234/24 broadcast 141.52.120.255
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 addr add 2a00:1398:8:203::10e8/64 dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 141.52.8.20/32 via 192.168.178.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 0.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 /usr/bin/ip route add 128.0.0.0/1 via 141.52.120.1
Mon Apr 2 12:30:12 2018 add_route_ipv6(2000::/3 -> 2a00:1398:8:203::1 metric -1) dev tun0
Mon Apr 2 12:30:12 2018 /usr/bin/ip -6 route add 2000::/3 dev tun0
Mon Apr 2 12:30:12 2018 Initialization Sequence Completed


So it seems the connection is working. Yet I can't ssh into any of the servers. I always get the error



ssh: Could not resolve hostname server.blabla.de: Name of service not known


Yet internet works perfectly (Does the internet use the vpn? How do I check this?)



How can I even debug this? I don't really know where to start.









share|improve this question













share|improve this question




share|improve this question








edited Apr 2 at 23:34









jasonwryan

46.6k14127175




46.6k14127175










asked Apr 2 at 8:33









Fl.pf.

1525




1525











  • Is "server.blabla.de" globally resolvable? Does dig server.blabla.de differ from dig @141.3.175.71 server.blabla.de? The server name you are requesting to may be only available through private nameservers, which are supplied by the OpenVPN server dhcp-option DNS parameters
    – Torin Carey
    Apr 2 at 14:25










  • @TorinCarey If I understand what you mean, then no. "server.blabla.de" can only be resolved any way if you are in the intranet. I am dualbooting and have no problem connecting to the servers in Windows 10.
    – Fl.pf.
    Apr 3 at 11:14
















  • Is "server.blabla.de" globally resolvable? Does dig server.blabla.de differ from dig @141.3.175.71 server.blabla.de? The server name you are requesting to may be only available through private nameservers, which are supplied by the OpenVPN server dhcp-option DNS parameters
    – Torin Carey
    Apr 2 at 14:25










  • @TorinCarey If I understand what you mean, then no. "server.blabla.de" can only be resolved any way if you are in the intranet. I am dualbooting and have no problem connecting to the servers in Windows 10.
    – Fl.pf.
    Apr 3 at 11:14















Is "server.blabla.de" globally resolvable? Does dig server.blabla.de differ from dig @141.3.175.71 server.blabla.de? The server name you are requesting to may be only available through private nameservers, which are supplied by the OpenVPN server dhcp-option DNS parameters
– Torin Carey
Apr 2 at 14:25




Is "server.blabla.de" globally resolvable? Does dig server.blabla.de differ from dig @141.3.175.71 server.blabla.de? The server name you are requesting to may be only available through private nameservers, which are supplied by the OpenVPN server dhcp-option DNS parameters
– Torin Carey
Apr 2 at 14:25












@TorinCarey If I understand what you mean, then no. "server.blabla.de" can only be resolved any way if you are in the intranet. I am dualbooting and have no problem connecting to the servers in Windows 10.
– Fl.pf.
Apr 3 at 11:14




@TorinCarey If I understand what you mean, then no. "server.blabla.de" can only be resolved any way if you are in the intranet. I am dualbooting and have no problem connecting to the servers in Windows 10.
– Fl.pf.
Apr 3 at 11:14










1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










The issue is that the server attempts to push nameserver addresses to the client (dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72), however, the client is not configured to interpret these parameters.



If you have resolvconf or openresolv installed, then it's worth using a script that often comes coupled with OpenVPN installations at /etc/openvpn/update-resolv-conf, to use this, simply add the following lines to the configuration file



up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


If not, you can temporarily work around this by changing /etc/resolv.conf to



nameserver 141.3.175.71
nameserver 141.3.175.72





share|improve this answer




















  • Thank you, I was indeed missing those two lines, and the script itself.
    – Fl.pf.
    Apr 3 at 18:09










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f434998%2fconnected-to-vpn-cant-ssh-into-server%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










The issue is that the server attempts to push nameserver addresses to the client (dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72), however, the client is not configured to interpret these parameters.



If you have resolvconf or openresolv installed, then it's worth using a script that often comes coupled with OpenVPN installations at /etc/openvpn/update-resolv-conf, to use this, simply add the following lines to the configuration file



up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


If not, you can temporarily work around this by changing /etc/resolv.conf to



nameserver 141.3.175.71
nameserver 141.3.175.72





share|improve this answer




















  • Thank you, I was indeed missing those two lines, and the script itself.
    – Fl.pf.
    Apr 3 at 18:09














up vote
1
down vote



accepted










The issue is that the server attempts to push nameserver addresses to the client (dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72), however, the client is not configured to interpret these parameters.



If you have resolvconf or openresolv installed, then it's worth using a script that often comes coupled with OpenVPN installations at /etc/openvpn/update-resolv-conf, to use this, simply add the following lines to the configuration file



up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


If not, you can temporarily work around this by changing /etc/resolv.conf to



nameserver 141.3.175.71
nameserver 141.3.175.72





share|improve this answer




















  • Thank you, I was indeed missing those two lines, and the script itself.
    – Fl.pf.
    Apr 3 at 18:09












up vote
1
down vote



accepted







up vote
1
down vote



accepted






The issue is that the server attempts to push nameserver addresses to the client (dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72), however, the client is not configured to interpret these parameters.



If you have resolvconf or openresolv installed, then it's worth using a script that often comes coupled with OpenVPN installations at /etc/openvpn/update-resolv-conf, to use this, simply add the following lines to the configuration file



up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


If not, you can temporarily work around this by changing /etc/resolv.conf to



nameserver 141.3.175.71
nameserver 141.3.175.72





share|improve this answer












The issue is that the server attempts to push nameserver addresses to the client (dhcp-option DNS 141.3.175.71,dhcp-option DNS 141.3.175.72), however, the client is not configured to interpret these parameters.



If you have resolvconf or openresolv installed, then it's worth using a script that often comes coupled with OpenVPN installations at /etc/openvpn/update-resolv-conf, to use this, simply add the following lines to the configuration file



up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf


If not, you can temporarily work around this by changing /etc/resolv.conf to



nameserver 141.3.175.71
nameserver 141.3.175.72






share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 3 at 11:30









Torin Carey

32016




32016











  • Thank you, I was indeed missing those two lines, and the script itself.
    – Fl.pf.
    Apr 3 at 18:09
















  • Thank you, I was indeed missing those two lines, and the script itself.
    – Fl.pf.
    Apr 3 at 18:09















Thank you, I was indeed missing those two lines, and the script itself.
– Fl.pf.
Apr 3 at 18:09




Thank you, I was indeed missing those two lines, and the script itself.
– Fl.pf.
Apr 3 at 18:09












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f434998%2fconnected-to-vpn-cant-ssh-into-server%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay