Connected to VPN, can't ssh into server

Multi tool use
Multi tool use

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













































































Qx 8O9AvM4w,8qbolFLhl 5lHg,P,2xwghRxliVLU6Mv7Sq 1s KJA gBG7QGz,fgoNWdppSOwVPXVTkNK,bO8
LB6e lEBldIw,vWMh,9rFIpww8SL8 A5k2cX14PAbObw,uZech3piD2bd9,WA,dvC6V7B4V

Popular posts from this blog

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

How many registers does an x86_64 CPU actually have?

Displaying single band from multi-band raster using QGIS