# Mullvad wireguard VPN messes with connection to FreeBSD servers



## veryuniquename (Feb 9, 2021)

I have a subscription at Mullvad and I use their Wireguard configuration. The connection works great and I have even faster network with Mullvad WG setup than without the VPN. There is one issue though, I cannot update my FreeBSD system. Whenever I try I get this:


```
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    166 B   0.2kB/s    00:01   
Fetching packagesite.txz:  22%    1 MiB  24.6kB/s    02:11 ETA
```

and then it is stuck like that... forever. Then I might cancel the update and try again and it looks something like this instead


```
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    161 B   0.2kB/s    00:01   
Fetching packagesite.txz:  12%  760 KiB   8.2kB/s    00:53 ETA
```

and I wait 15 minutes and it is still the same message.

If I run `wg-quick down mullvad` and then update it works flawlessly like below


```
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    169 B   0.2kB/s    00:01   
Fetching packagesite.txz: 100%    2 MiB   2.1MB/s    00:02  
Processing entries:   0%
Processing entries: 100%
FreeBSD repository update completed.
All repositories are up to date.
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
```

When I ping frebsd.org or update.freebsd.org I get no response, but when I ping literally any other site or server I get a response.

This is my ifconfig (modified for privacy)


```
re0: flags=8888<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1600
    options=8888b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
    ether 11:11:11:11:11:11
    inet 192.168.1.100 netmask 0xffffffff broadcast 192.168.1.1
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=30<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


mullvad: flags=8125<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1440
    options=80000<LINKSTATE>
    inet 10.70.220.1 --> 10.70.220.1 netmask 0xffffffff
    groups: tun
    nd6 options=100<PERFORMNUD,NO_DAD>
    Opened by PID 60222
```

any ideas as to why the only connection that is messy with wireguard is FreeBSD? Is FreeBSD being blocked for any reason because I am using mullvads DNS server and they have flagged the FreeBSD update server for some reason? Last note: I can sometimes update despite being connected to a mullvad wireguard server. Rare but sometimes it happens.


----------



## SirDice (Feb 9, 2021)

It's possible you get transferred to a different mirror with or without the VPN. The pkg.freebsd.org gets redirected based on the GeoDNS location. With the VPN on you might be hitting a bad mirror. 



veryuniquename said:


> Is FreeBSD being blocked for any reason because I am using mullvads DNS server and they have flagged the FreeBSD update server for some reason?


That's a question you should ask Mullvad.


----------



## veryuniquename (Feb 9, 2021)

SirDice said:


> It's possible you get transferred to a different mirror with or without the VPN. The pkg.freebsd.org gets redirected based on the GeoDNS location. With the VPN on you might be hitting a bad mirror.
> 
> 
> That's a question you should ask Mullvad.


I was just wondering if anyone knew anything about Mullvad's blocking list and if it affected them in any way. Maybe Mullvad has not disclosed the whole extent of their filtering list, for example. Further I am unsure if it is a bad mirror since the connection just halts. I was under the assumption that after a certain amount of time (I think 30 seconds is default) it retries, and the default is three retries. However it doesn't even give me a "time out" error or anything, it just halts, as if it recieves keep alive packages but not the actual package itself or something. Seems weird I can start an update or upgrade or install (anything fetch related + freebsd server) and come back after an hour of lunch break and it still is at "fetching meta.conf 170 B size". Thanks for the input though!


----------

