Running Into Issue with VPN Mullvad Tutorial.
-
@thenuge Why are you changing the monitor IP? I used to have a WG link to Mullvad and I don't recall having to change that from default.
-
@kom from what I got from the video. The mullvad IP they give you will not actually work as a monitoring IP. Even if the gateway is down it will always show up because its an internal IP . By switching it to a real DNS location. I used 9.9.9.9 it actually provides a monitoring function and will show if your gateway is actually up or not.
Changing the monitoring IP is not the reason my gateways are down (at least I don't think it is, again, not an expert.) But by doing this I am actually seeing that they are down. If I switch that back they will show online again. -
@thenuge I never noticed an issue before but I don't run it anymore so I can't help you any further. Good luck with your issue.
-
@thenuge When I first set this up using the same tutorial (different provider) my gateways would go offline constantly as well.
Coincidentally, for my monitoring IPs I was using 9.9.9.9, 8.8.8.8 and 1.1.1.1. I've since switched to using 8.8.4.4, 1.0.0.1 and 9.9.9.10 and so far these seem more 'reliable'. No constant gateway down notifications. May have been a fluke but that's my experience so far.
What other addresses have you tried besides 9.9.9.9?
-
@thenuge said in Running Into Issue with VPN Mullvad Tutorial.:
The Mullvad IP they give you will not actually work as a monitoring IP. Even if the gateway is down it will always show up because its an internal IP .
That's correct. In setting up the wiregurd tunnels in pfsense you use the Mullvad IP for the Wireguard IP address of the pfsense wireguard gateway. So monitoring that address will always show that the interface is up because it's looking at the pfsense side of the tunnel. You need to use an IP address across the tunnel as the monitor IP.
Try doing an traceroute from pfsense by way of each Mullvad interface. Note the IP addresses for the first and second hops in each of the traceroutes. Those addresses are usually always servers still within Mullvad's infrastructure. Do a ping test to those IPs. If they return responses try using them for the monitor IPs. Alternatively lookup Mullvad's DNS servers IPs and test them with a ping as well. They can work too if they respond to pings.
I've found this to be way more stable than using something like 8.8.8.8, etc. which is dependent on many more hops routing across the internet to finally get to its destination.
-
I have tried a bunch of DNS servers as different monitors but at this point I think this issue is a symptom of something else and not the actual issue. I believe my gateways are actually not working which is why the monitors are show them as down.
The order in the picture goes.
Packets in
Packets outBytes In
Bytes OutErrors In
Errors Out
Lots of errors.
-
@thenuge I think you might have an issue with either your firewall rules or your NAT rules. Can you post screenshots of them?
Also, do a ping test Diagnostics/Ping, with the Source Address as each of your Mullvad tunnels, to 8.8.8.8 and google.com. Do the tests come back correctly, if not which ones fail?
-
-
@thenuge I do not use Mullvad, I use IVPN, but I did use Christian's video on setting up my IVPN interface group. My setup is working.
I have 3 different interfaces/tunnels set up to my provider. None of the interface's on my setup have any firewall rules set up in them. Same goes for the Wireguard Interface. They all look like this:
You do need to have a policy routing rule on the interface where your host are (LAN?) that are sending traffic across the tunnel to Mullvad. It would look like this:
One thing to note. I'm pretty sure that Wireguard only transmits UDP packets. So any rule you would want to apply on the Mullvad interfaces would have to have UDP in the protocol.As to NAT, it looks to me like you setup an Interface Group for your tunnels to Mullvad and then used that interface group to create one NAT rule for the 3 interfaces. That is how Christian did it in his video.
I originally set mine up without the interface group. So I had a NAT rule for each interface. Everything worked perfectly like that. I then created an interface group and created a single NAT rule using the interface group, as described in Christian's video, and everything broke. I could not get anything working across the tunnels. I undid the interface group and recreated the individual NAT rules for each interface and everything started working again. I've left it like that ever since and it's working fine.
You might want to get rid of the interface group and apply individual NAT rules to each interface and see if that fixes it.
-
@dma_pf The funny thing is I started off trying to use IVPN over mullvad but the public key / private key stuff was confusing me so I went with mullvad because they provided that file with everything nicely labeled like in the video. Figured I would switch back later once I got a better handle on everything unless I fell in love with mullvad.
I deleted the firewall rules, and the interface group and added a lan rule. Im going to keep messing with it and get back with an update asap.
-
Alright... I figured out my issue. I never added allowable IP's to 0.0.0.0 /0.
That problem is fixed but I still cannot get my lan traffic or my openvpn tunnel client to use those tunnels for internet. Road block after road block. I guess if this was easy everyone would do it.
