Internet/VPN problem

I recently upgraded to Suse 11.3. The internet was working fine.
I use VPN (using KVpnc) and Remote into my computer at work. This worked fine. But ever since I did this for the first time, I can only connect to the internet if I first connect to my work network using VPN.

Any ideas?

Thanks in advance.

Joel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wildly guessing… a DNS resolution or a routing problem. Does a reboot
fix things? How about providing output to the following commands:

ip addr
ip route
cat /etc/resolv.conf
ping -c 2 8.8.8.8
ping -c 2 google.com

Good luck.

On 02/11/2011 01:36 PM, urisk1323 wrote:
>
> I recently upgraded to Suse 11.3. The internet was working fine.
> I use VPN (using KVpnc) and Remote into my computer at work. This
> worked fine. But ever since I did this for the first time, I can only
> connect to the internet if I first connect to my work network using
> VPN.
>
> Any ideas?
>
> Thanks in advance.
>
> Joel
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNVcArAAoJEF+XTK08PnB53boQAJnBHaSmPgMZIXfg6/Jkw52O
ErqXafyM09J8gVQNBNiX3fbCg410skRLNyxIbtioOKK8f3U0Mwbua5x7TImZElF7
Mw1bCLPPsSz+fniC9xxocB1kdlts95nYxogJnYJzeZ7BuRxg0UUe+1RAuydTvdmZ
UuGiKvR6fj339NruNYcBHVqiEQKe6QFxiwxvlUzoD26CBDqf1Xqo14nr8TPFEr1C
qTAMo0U9BDH8td7WwZxDqCE5kTU8Lw9nf1bPIHwHd7tfHaoYZDvl1VlHugUsBu+u
KJ7ciNO1YjO5EEVdePw4DJP/5/lhJkKzXVMTfrOVLbDZbpWsygN4yn9QOCro49uR
NNifH4HpWZo5LjLsuZxtKl4tN7FeUkEbbq5z6CVVXVbJaNrsjAG7wO7pT3w8dPfL
KpaYj0AOdQgC76eRaoNHt4smeqrNJD5a5xha4zlqMcjZrI4ZCyysVVJs2xy9GBjL
1xecZC4Hiko0Y6ZwTUY6XgIXngyIq3ox+deiiXfn5BA5BSr9wSXSjVbeiXezMJjx
9DTLbDW3br7rd383usZtflQWgNSW+FaxojFwK/u22SatxIPNy80AmcaGQsOqybY8
oAmPeUfNMZIMbmq/llM2Xol3aTiDd7csm8yv0ka2BKZMO4rQPmYT382A1qJhQhVt
P3/NuBX04eFzyEknOco2
=y/uE
-----END PGP SIGNATURE-----

Here are the results. This is while I am connected to the VPN:

urisk@Kali:~> ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 576 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:0d:87:be:e2:79 brd ff:ff:ff:ff:ff:ff
inet 76.105.217.112/22 brd 255.255.255.255 scope global eth0
3: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1390 qdisc pfifo_fast state UNKNOWN qlen 500
link/none
inet 192.168.100.50/32 scope global tun0
urisk@Kali:~> ip route
10.33.0.3 dev tun0 scope link
10.33.0.2 dev tun0 scope link
173.164.84.41 via 76.105.216.1 dev eth0 src 76.105.217.112 mtu 576 advmss 536
76.105.216.0/22 dev eth0 proto kernel scope link src 76.105.217.112
10.33.0.0/16 dev tun0 scope link
169.254.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 76.105.216.1 dev eth0
urisk@Kali:~> cat /etc/resolv.conf
#@VPNC_GENERATED@ – this file is generated by vpnc

and will be overwritten by vpnc

as long as the above mark is intact

#@VPNC_GENERATED@ – this file is generated by vpnc

and will be overwritten by vpnc

as long as the above mark is intact

/etc/resolv.conf file autogenerated by netconfig!

Before you change this file manually, consider to define the

static DNS configuration using the following variables in the

/etc/sysconfig/network/config file:

NETCONFIG_DNS_STATIC_SEARCHLIST

NETCONFIG_DNS_STATIC_SERVERS

NETCONFIG_DNS_FORWARDER

or disable DNS configuration updates via netconfig by setting:

NETCONFIG_DNS_POLICY=’’

See also the netconfig(8) manual page and other documentation.

Note: Manual change of this file disables netconfig too, but

may get lost when this file contains comments or empty lines

only, the netconfig settings are same with settings in this

file and in case of a “netconfig update -f” call.

Please remove (at least) this line when you modify the file!

search hsd1.or.comcast.net. eug.cascadesoftwaresystems.com eug.cascadesoftwaresystems.com
nameserver 10.33.0.2
nameserver 10.33.0.3
urisk@Kali:~> ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=34.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=33.9 ms

— 8.8.8.8 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 33.927/34.087/34.247/0.160 ms
urisk@Kali:~> ping -c 2 google.com
PING google.com (74.125.155.99) 56(84) bytes of data.
64 bytes from px-in-f99.1e100.net (74.125.155.99): icmp_seq=1 ttl=50 time=35.4 ms
64 bytes from px-in-f99.1e100.net (74.125.155.99): icmp_seq=2 ttl=50 time=36.3 ms

google.com ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 5083ms
rtt min/avg/max/mdev = 35.497/35.919/36.342/0.463 ms
urisk@Kali:~>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

K, that’s what I’d expect while connected. My original theory about DNS
issues will still hold true if you only have those 10.x.x.x IPs in
/etc/resolv.conf AFTER you disconnect from the VPN since your machine,
when disconnected, cannot reach those boxes. Give it a try. If I’m
correct, try adding back some other DNS server into that file (8.8.8.8 is
a free one from Google that always works) and see if that makes your
pinging (both ways as shown before)work again while still disconnected
from the VPN. If so, confirmed. Post output, please.

Good luck.

On 02/12/2011 08:36 AM, urisk1323 wrote:
>
> Here are the results. This is while I am connected to the VPN:
>
> urisk@Kali:~> ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 576 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> link/ether 00:0d:87:be:e2:79 brd ff:ff:ff:ff:ff:ff
> inet 76.105.217.112/22 brd 255.255.255.255 scope global eth0
> 3: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen
> 1000
> link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
> 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1390 qdisc
> pfifo_fast state UNKNOWN qlen 500
> link/none
> inet 192.168.100.50/32 scope global tun0
> urisk@Kali:~> ip route
> 10.33.0.3 dev tun0 scope link
> 10.33.0.2 dev tun0 scope link
> 173.164.84.41 via 76.105.216.1 dev eth0 src 76.105.217.112 mtu 576
> advmss 536
> 76.105.216.0/22 dev eth0 proto kernel scope link src 76.105.217.112
> 10.33.0.0/16 dev tun0 scope link
> 169.254.0.0/16 dev eth0 scope link
> 127.0.0.0/8 dev lo scope link
> default via 76.105.216.1 dev eth0
> urisk@Kali:~> cat /etc/resolv.conf
> #@VPNC_GENERATED@ – this file is generated by vpnc
> # and will be overwritten by vpnc
> # as long as the above mark is intact
> #@VPNC_GENERATED@ – this file is generated by vpnc
> # and will be overwritten by vpnc
> # as long as the above mark is intact
> ### /etc/resolv.conf file autogenerated by netconfig!
> #
> # Before you change this file manually, consider to define the
> # static DNS configuration using the following variables in the
> # /etc/sysconfig/network/config file:
> # NETCONFIG_DNS_STATIC_SEARCHLIST
> # NETCONFIG_DNS_STATIC_SERVERS
> # NETCONFIG_DNS_FORWARDER
> # or disable DNS configuration updates via netconfig by setting:
> # NETCONFIG_DNS_POLICY=’’
> #
> # See also the netconfig(8) manual page and other documentation.
> #
> # Note: Manual change of this file disables netconfig too, but
> # may get lost when this file contains comments or empty lines
> # only, the netconfig settings are same with settings in this
> # file and in case of a “netconfig update -f” call.
> #
> ### Please remove (at least) this line when you modify the file!
> search hsd1.or.comcast.net. eug.cascadesoftwaresystems.com
> eug.cascadesoftwaresystems.com
> nameserver 10.33.0.2
> nameserver 10.33.0.3
> urisk@Kali:~> ping -c 2 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=34.2 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=33.9 ms
>
> — 8.8.8.8 ping statistics —
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 33.927/34.087/34.247/0.160 ms
> urisk@Kali:~> ping -c 2 google.com
> PING google.com (74.125.155.99) 56(84) bytes of data.
> 64 bytes from px-in-f99.1e100.net (74.125.155.99): icmp_seq=1 ttl=50
> time=35.4 ms
> 64 bytes from px-in-f99.1e100.net (74.125.155.99): icmp_seq=2 ttl=50
> time=36.3 ms
>
> — google.com ping statistics —
> 2 packets transmitted, 2 received, 0% packet loss, time 5083ms
> rtt min/avg/max/mdev = 35.497/35.919/36.342/0.463 ms
> urisk@Kali:~>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNVrX2AAoJEF+XTK08PnB5UyoP/3ihO/xh4pAta6FeUzmN4NPf
nMuEOdRdvzrHq5cMfRIiykNLJKoK8QGfQy/h0J20rNrc615oG+u6rM0b1/fjOtwU
sBd8omKIg3xSH4H3cuh/NB1dGsoQIHmbc6ZgJtvHO1NXjvyDOhnI1tffz/Om7GFM
ACpKP7Y2r1KJKiBmQToQm/N7KG9+bZzFxAV6yhJIac/tZyqZTuQ+lhLS1jqz+/Qc
nl8qT3Yj78BoudqoASWZ+Xzmj9iXWCrpnSQRC/46qusP0rQjTG+Xa2aRqDTR9pwR
aOx8Bm25XiUil1ExwXn/tmm2ajEa+VoyeHw2WqhYqkvBsbgHCrImGtXud6gVlREQ
KoiwN48iEbkHjKzB+QB5+f2gQxsmJv0r2JOY8n+hNjqdTiLtPOxYedyTQLwnpdzy
jrzebefaoC2kh6ye5uLrQrPoaOQ8Xqm1ScSW7xgJZQGY4BqjA0FtsFH3SlAqVzxr
e6Ju3FvY9A6THmyOUL7vg1fdtUUrlBERWgSEgoCA0RMM1vVNKb2zmHcTAhaJ1VsZ
5Zqjb2lhpn3fPeBUCs2gD3pOBqFT/HVCu97tmv+hnShA4BPeD47GR5ls+MGyl4Zc
2ZVJjviGesKPIMK696485ej+FUkVDG6XBEQprRO1u/rIqKvklSW4rMjikMulpK5u
xzcnHor/smRiyH11tqQD
=CAEp
-----END PGP SIGNATURE-----

You were correct on all counts. Adding the 8.8.8.8 dns server worked. Thank you very much.

I hate to sound like a noobe, but when you say “Post output.” What do you mean? Do you want more info than, “it fixed the problem”?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glad it worked. By ‘post output’ I mean of the ping commands, but since
the issue is confirmed that’s not necessary; I was requesting it in case I
was wrong (it happens… a lot).

So the problem is that your VPN client is not restoring your DNS stuff
when it shuts down. Simple enough workaround, but the ultimate fix is to
have your networking stuff (probably your VPN client, KVpnc) to put things
back when it’s done connecting you to your remote network.

Good luck.

On 02/12/2011 11:36 AM, urisk1323 wrote:
>
> You were correct on all counts. Adding the 8.8.8.8 dns server worked.
> Thank you very much.
>
> I hate to sound like a noobe, but when you say “Post output.” What do
> you mean? Do you want more info than, “it fixed the problem”?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNVwyaAAoJEF+XTK08PnB5MNYQAM7tyj+B1blOq2AtyRuyMZVh
lo/USLvZJOEBxREUcZNwHzYbgS/20CFn3IBLiqHzKHGHM8RLcK5v2QC4qWDBVX22
drfJI6S292kJ/POl+vTJSVl1w23Ceb408NTd+SSq37ZQ22sbVmABHQjRyOlwVp8n
+cQMLtq5bzuRXEgfnqxSjvVdFolX/SiV7Zix4aLv8xPGWczYItTk29SuaSlkXp0r
3Y/04iQNpBNxPM3wsBtjDW3YNHWSXAZ2cvWSPA+eg74VhEQ/5+ezWP0RJyBqd6qT
FwqtLwYoQ+PuIEe9WWWPlK3HB4ec8XFtHp9Dxa/6CYpB6/EjJdwFlau++P07f9m4
AZZyhzUTNY1tE+QUbx94uqFPUDvzgYCNpkC/JkF/aPg4SgzNLbsWLdI6BUn7fi7y
/a3NXimxHTYQ91a6qELFEaE2kw8P0o0bWfY0FdVEbHYX04lhNCvEhn+NTgf2isMI
ceahKCn8YJyn/JEOZp+GQxely1zTCZ9Zmlhkbsoepjna4QTivdWC/1YNc4HVi4zJ
eBWMM+7Bp1JMmzAjJd6ODfJxwQ9549OcrOQcEyg95WykndNkn6GUC9P9LLHUFOgX
nLQ3RRGrRaIc5g5t81KwQYUSdJq6VlNUaBKnpq6IK0H9rsL5C7V++vtZsDaO72Tm
CjsPgNMVqZW1ITAJuPDX
=ANsT
-----END PGP SIGNATURE-----

I’m using the KDE4 network management applet to connect to our (PPTP) VPN. If connected, all I need to do is click on the relevant icon to disconnect and return the routing and DNS to the original state. (Actually, it does leave one route in place, but it doesn’t affect my internet connection).

Does this not work for you? Maybe you need kvpnc for some other type of VPN connection?