Fedora is unable to visit university websites when connecting to its WPA2-Enterprise wifi on VPN

Ask Fedora
,
1

I encountered several VPN related bugs when using Silverblue 38 which I didn’t have in MicroOS, another immutable distro.

1. Windscribe VPN not able to connect to any server.
2. I wasn’t able to connect to my university’s websites if I connected to my university wifi. Other websites ran totally fine. This happened to three VPN providers I tested. Already reported the bug here.

It seems VPN experience on Silverblue 38 has been…rocky. I’m wondering if any body else had the same issue here. Would might be the causes of the VPN issues?

I found myself unable to open any of my university’s websites if I connected to my university wifi (WPA2-Enterprise) when using a VPN. No matter which connection method I tried and which server I tried it remained the same. I have tried multiple VPN providers (Mullvad, iVPN, and Windscribe), and the results were the same.

However, I was able to connect to my university’s websites when I connected to my phone hotspot instead of my university wifi. I didn’t have this VPN issue when using other Linux OS before.

Is there any workaround to fix this? Thanks!

1 Like
2

is it only after fedora38?
1)A naive assumption is that your uni website just blocks any connection with device fingerprint “Fedora/linux” since some admin could be quite (funny or lack of experience).They just assume anyone using linux is a Hacker*.
2)Your vpn is just those common advertised vpn.they even kept your OS environment in your connection.great privacy! while using hotspot probably overwritten the connection.OS as android.In naive sense your hotspot has better privacy.

3

Not quite sure if 37 has the issue since I just started using Silverblue a few days ago.

I’m pretty sure my uni doesn’t block Linux or Fedora. If I opened the uni website without VPN there was no connection problem.

6

I found that the problem only happened when I used the VPN app, no problem at all when I connected VPN through Wireguard configuration files.

7

The workaround I used was to enable SOCKS 5 proxy in Firefox with VPN.

8

Someone just had the same issue on Fedora Workstation, so it might be a upstream issue rather than Silverblue-specific one. Unable to connect to institution's websites when connecting to its WPA2-Enterprise network on Silverblue · Issue #4633 · mullvad/mullvadvpn-app · GitHub

9

Finally got around to submitting a bug report for this

https://bugzilla.redhat.com/show_bug.cgi?id=2271283

10

Since Silverblue 41 I no longer have the issue. I’m using Windscribe.

11

Unfortunately with Workstation 41 and Mullvad, this issue persists for me :frowning:

Have you tried other VPNs to see if they work or just windscribe?

12

I just tried Mullvad, and the problem persists just like you said unfortunately.

15

Split tunneling does not resolve the issue

17

Idk either. I’ve had this issue for years with multiple linux distros with multiple vpn providers with eduroam networks at different institutions.

19

Thank you for the help. The outputs are below.

With VPN disconnected:

$ resolvectl status --no-pager
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp170s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: 8.8.4.4
       DNS Servers: 8.8.8.8 8.8.4.4
        DNS Domain: umhs.med.umich.edu med.umich.edu umich.edu

$ resolvectl query wolverineaccess.umich.edu --legend=no
wolverineaccess.umich.edu: 52.26.197.105       -- link: wlp170s0
                           52.39.196.164       -- link: wlp170s0
                           52.11.222.16        -- link: wlp170s0
                           35.160.17.38        -- link: wlp170s0
                           (one2-1751943943.us-west-2.elb.amazonaws.com)

$ resolvectl query www.googletagmanager.com --legend=no
www.googletagmanager.com: 2607:f8b0:4009:81c::2008 -- link: wlp170s0
                          142.251.32.8         -- link: wlp170s0

With VPN connected:

$ ip route show table all
default dev wg0-mullvad table 1836018789 proto static 
default via 10.65.0.1 dev wlp170s0 proto dhcp src 10.65.34.72 metric 600 
10.64.0.1 dev wg0-mullvad proto static 
10.65.0.0/17 dev wlp170s0 proto kernel scope link src 10.65.34.72 metric 600 
local 10.65.34.72 dev wlp170s0 table local proto kernel scope host src 10.65.34.72 
broadcast 10.65.127.255 dev wlp170s0 table local proto kernel scope link src 10.65.34.72 
local 10.135.195.24 dev wg0-mullvad table local proto kernel scope host src 10.135.195.24 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
fe80::/64 dev wlp170s0 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::583:a017:2563:202a dev wlp170s0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev wlp170s0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wg0-mullvad table local proto kernel metric 256 pref medium

$ ip rule show; ip -6 rule show
0:	from all lookup local
32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0x6d6f6c65 lookup 1836018789
32766:	from all lookup main
32767:	from all lookup default
0:	from all lookup local
32766:	from all lookup main

$ resolvectl status --no-pager
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp170s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: 8.8.4.4
       DNS Servers: 8.8.8.8 8.8.4.4
        DNS Domain: umhs.med.umich.edu med.umich.edu umich.edu

Link 12 (wg0-mullvad)
    Current Scopes: DNS
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: 100.64.0.55
       DNS Servers: 100.64.0.55
        DNS Domain: ~.

$ grep -e hosts /etc/nsswitch.conf
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

$ grep -v -e ^# /etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad
search umhs.med.umich.edu med.umich.edu umich.edu
1 Like
21

Thank you for all the information!

I think this is unlikely since simply enabling socks5 makes it work properly, but split tunneling does not, and because I have never had trouble reaching the website while off site, even with the VPN enabled.

I will try your suggestions next time I am on site.

23

Actually, Mullvad allows split tunneling to public ip addresses as well. I can access any other public website when split tunneling is enabled - but not my institution’s website. Does this mean that your solution is unlikely to work? Correct me if I’m not understanding something.

1 Like
25

Right, but you’re not on my institution’s wifi network. I can also access the website over VPN when I’m not on my institution’s eduroam wifi network.

1 Like
26

Split DNS is the only difference between this Wi-Fi network and any other network where the site works correctly while using the same VPN.

The easiest workaround should be disabling split DNS to eliminate the difference:

# Runtime
sudo resolvectl dns wlp170s0 ""
sudo resolvectl domain wlp170s0 ""

# Permanent
while IFS=":" read -r UUID DEVICE
do if [ "${DEVICE}" = "wlp170s0" ]; then break; fi
done < <(nmcli -g UUID,DEVICE connection show)
sudo nmcli connection modify ${UUID} \
    ipv4.ignore-auto-dns yes \
    ipv6.ignore-auto-dns yes \
    ipv4.dns 8.8.8.8,8.8.4.4
sudo nmcli connection up ${UUID}
2 Likes
27

Wow, this worked! Thank you. I’m not seeing any Mullvad DNS leaks either.

1 Like