no internet after disconnecting vpn

English Network/Internet
1

Hello,

I’m having problems with my internet connection. I use AirVPN, but have to disconnect here and there to access Chinese websites. However, when I disconnect I don’t get internet connection anymore, also can’t do updates etc. The wifi symbol might end up showing a question mark. Even after restarts the problem still persists (even though it might be because I had the VPN set to autostart, not certain right now). Does someone know why this happens and how/if I can fix it?

Thanks for any help :slight_smile:

2

  1. Are you connecting via NetworkManager or are you using wicked?

  2. When you next disconnect, capture the following

ip addr

ip route

grep name /etc/resolv.conf

If you need to save this output to a text file, so that you can post the information when you do have internet connectivity.

3

I’ve found similar behaviour is described in this Ubuntu bug report. I’m cautious about it being due to the same regression as Uubuntu uses dnsmasq and resolvconf in the mix, but I think an openSUSE bug report might be a good idea to help progress this.

4

My output for ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:a4:71:6e:e8:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic wlp3s0
       valid_lft 86019sec preferred_lft 86019sec
    inet6 fe80::39d8:fb3b:b6a4:8e75/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether c8:5b:76:38:1a:fe brd ff:ff:ff:ff:ff:ff

For ip route:

default via 192.168.1.1 dev wlp3s0 proto static metric 600 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.3 metric 600 
194.187.251.156 via 192.168.1.1 dev wlp3s0

And for grep name /etc/resolv.conf:

nameserver 192.168.43.1

I’m not sure how to do this, never reported a bug. Could I simply link to the Ubuntu bug report?

5

The IP addressing looks ok, although after disconnecting I’m surprised this (VPN-specific) route is not cleaned up…

194.187.251.156 via 192.168.1.1 dev wlp3s0

It shouldn’t be impacting though as there is still a default route in place as expected

This nameserver is likely the issue as I assume that is set via the active VPN connection

nameserver 192.168.43.1

This means when you disconnect from the VPN you will no longer be able to resolve internet hosts. Normally, I’d expect to see the router address present (192.168.1.1) if it handles DNS forwarding, or a publicly accessible DNS IP address.

I’m not sure how to do this, never reported a bug. Could I simply link to the Ubuntu bug report?

No, you’d need to post a bug with a concise description that can include output (like you’ve already posted here), demonstrating that when you disconnect the name server is not being updated as expected.

BTW, when you next disconnect from the VPN and can’t resolve hostnames (eg browsing) run

sudo netconfig -f update

then check that you can now browse again using the regular internet connection.

It should result in valid name servers being applied again…

grep name /etc/resolv.conf
6

Further to your concern about submitting a bug report, this openSUSE:Submitting_bug_reports guide is helpful.

Then submit here:
https://bugzilla.opensuse.org/buglist.cgi?quicksearch=prod%3A"openSUSE%20Tumbleweed"&list_id=6591992

7

Thanks, netconfig -f update is very useful. :wink:

I will check it out and report the bug.

8

Although it shouldn’t be necessary,
You can also try restarting your networking service to ensure your networking configuration changes are re-read…

systemctl restart network.service

The above command should work regardless whether you’re using Wicked or NM to manage your networking.

TSU

9

Addendum/explanation to my suggestion…

systemd experts might notice that if the systemd Unit file (which is the configuration file for that app or service) requires a “daemon reload” if the Unit file itself is changed.

But, in this case, the networking service itself is not modified, the modified parts are the dependencies… So that is why you can simply restart the networking service and it should work.

I’ve started listing some “should know” systemd commands on a Wiki page (anyone can modify/add something if you wish). and might become a reference for people who are first learning systemd commands

https://en.opensuse.org/User:Tsu2/systemd_commands

TSU

10

I haven’t gotten on it yet (sorry about that), but had to do format my system. Now this issue doesn’t seem to exist anymore. Do you know if there has been a fix within the latest updates or should I still report this bug?

11

I’m not sure. If it’s working currently then I’d just park this for now. (Not aware of others reporting similar currently.)