On a firewall using two Mullvad GWs which I set up more than a year ago one of the GWs went down this week. A deeper look revealed the server has been redeployed, same name but different IPs and WG keys.
As I've dealt with this in the past I went to update the GW configuration in all the required places, and all went fine except when trying to update the IP in Interfaces. The error when trying to save the new IP is Cannot assign an IP configuration type to a tunnel interface
As you can see below, both opt13 and opt14 have the same settings, yet I couldn't update the IP in the GUI, so I just did it in config.xml and service was restored.
<opt13>
<if>wg2</if>
<descr>WAN_M0</descr>
<enable>1</enable>
<spoofmac/>
<ipaddr>10.175.221.69</ipaddr>
<subnet>32</subnet>
<gateway>WAN_M0</gateway>
</opt13>
<opt14>
<if>wg3</if>
<descr>WAN_M1</descr>
<enable>1</enable>
<spoofmac/>
<ipaddr>10.22.47.75</ipaddr>
<subnet>32</subnet>
<gateway>WAN_M1</gateway>
</opt14>
I don't set up Mullvad too often which is why I cannot pinpoint the OPNsense time frame this GUI restriction b]Cannot assign an IP configuration type to a tunnel interface[/b] has been added. It is clearly required though so I'm hoping Franco or Ad can look into it.
For reference, this is the tutorial I follow/revisit anytime I need to set up or update a WG configuration
https://schnerring.net/blog/opnsense-baseline-guide-with-vpn-guest-and-vlan-support/ (https://schnerring.net/blog/opnsense-baseline-guide-with-vpn-guest-and-vlan-support/)
That interface page validation is quite old and proper. A VIP would work as well I suppose?
Cheers,
Franco
Hi Franco,
I don't think a VIP is the answer here, the WG interface needs to have a static IP, and it's the static IP field at the bottom of the page that is now throwing out the input validation error - although it worked just fine in the past.
As mentioned, doing the IP change in the config.xml was the workaround I needed to restore the service.
No, IPv4 and IPv6 setups of tunnels are not allowed in the interface page. It may have worked for wireguard being a plugin a while back missing the proper registration, but it's quite strange. A VIP is really the same and you can add it without setting IP modes. It also works for GIF/GRE tunnels where it is used to add different aliases if needed.
https://github.com/opnsense/core/commit/e40b8f51ac30a
Cheers,
Franco
Ah I see now, so i looks like the changes would go in this section in the screenshot.
Would it be possible to amend the Cannot assign an IP configuration type to a tunnel interface message with a reference to the VIP section then ? I don't know how common this practice was in the past or in how many other tutorials the static IP or a tunnel is mentioned on the interface, so having a clarification in the error message would be helpful.
I'll ping schnerring in a PM as it looks like the tutorial needs to be updated.
Thanks again Franco.
It looks like there is a bug now in conjunction with this mullvad way of configuring an IPv4 manually... see https://github.com/opnsense/core/issues/6934
Cheers,
Franco
Ok it looks like the user on GitHub made the following mistake: used x.x.x.x/32 for the tunnel address, but his network was x.x.x.x/24 and prior to 23.7.6 the IPv4 could be set to x.x.x.x/24 to fix it but in reality the better fix is to not set the IPv4 and instead set the tunnel address to x.x.x.x/24 (and clear the IPv4 config in that case if used).
The similar problem probably appears for Mullvad. It might have been a limitation of wireguard-go at the time?
Cheers,
Franco
Hi Franco,
I was reading the evolving thread on GH, and while I cannot say or sure if there ever was a limitation on wireguard-go, I'm 99% sure I created most of he Mullvad GWs on the kmod - while I installed the moment it became available and never looked back.
Now I have two comments on this issue if you don't mind.
- First, Ad's (?) suggestion of using a /24 may be fine for someone in control of both ends of WG, but I'm not terribly fond of the idea...should I have to set up such a thing. I also tried with a /31 before modifying config.xml and didn't work. Both GWs are running fine for more than a year on /32.
- Secondly, while I understand the reasoning of having those tunnel settings in the VIP section I would argue that is the less fortunate from a user experience and even logical point of view.
===================
I would propose amending the Interface GUI with a hidden by default VIP section. This would allow all Interface related settings to be present on a single page - which would be great for usability.
Also, for consistency, all VIP information added on an interface would be presented as an entry in the Virtual IP section as well.
===================
- Lastly, I did a quick search for WG tutorials from other VPN providers here and on the internet - trying to asses whether the VIP thing will be required for more than only Mullvad, and so far I haven' found another. Best written one I found is from iVPN and they don't even go anywhere near a GW in Interfaces...
https://www.ivpn.net/setup/router/opnsense-wireguard/ (https://www.ivpn.net/setup/router/opnsense-wireguard/)
My proposal may hold some value from a user experience point of view, but if we're only talking Mullvad AND Wireguard - whose lack of updates are a growing concern - Virtual IP section will have to do.
Thanks again :)
Hi there,
> First, Ad's (?) suggestion of using a /24 may be fine for someone in control of both ends of WG, but I'm not terribly fond of the idea...should I have to set up such a thing. I also tried with a /31 before modifying config.xml and didn't work. Both GWs are running fine for more than a year on /32.
/32 has the downside of telling the local end that this is a point to point setup only being able to reach the gateway. However in the thread you could see that the user wanted /24 and actually configured it in the IPv4 config likely so he could access other peers from this box. If that's not what you want you can use /32. Bottom line is if you configured both /32 and /24 it's likely /24 is configured on the ifconfig output... which is why it was added as a workaround in the first place.
> Secondly, while I understand the reasoning of having those tunnel settings in the VIP section I would argue that is the less fortunate from a user experience and even logical point of view.
The thing is you don't need this. This is what the tunnel address is for...
Cheers,
Franco
Quote from: franco on October 13, 2023, 10:29:15 AM
The thing is you don't need this. This is what the tunnel address is for...
I'll deploy a VM this weekend and test. Would be awesome to get rid of unneeded complications.
For reference see:
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/Wireguard/wg-service-control.php#L70L73
VIPs or IPv4/6 interface configuration does exactly the same.
Cheers,
Franco
I am a Mulvad user that discovered my wireguard configuration no longer works. I have attempted to follow the different discussions on this but the only real answer is that I've had things configured wrong this whole time.
I have attempted to use VIPS to assign an IP to the interface and the interface and it appears to come up in the gui but no traffic is passed. Is there a solution to this? Have any guides been updated? It's just frustrating to hear that "Your configuration is incorrect" when it has worked for so long.
<Solved> I was able to get it properly configured by adding the VIP addresses and including outbound/NAT entries for the WG interface. Maybe I should write a guide.
Thanks townsenk, interestingly enough and quite unexpectedly I hit the NAT issue as well for reasons I don't understand.
First thing, on topic, it's not pretty but it works just fine with the VIPs on 23.7.6.
================================================
Migratory birds - from Interface IP/GW to VIP - need to do the following:
a) Go to Mullvad Interface(s) - Copy IP/32 and GW - Set IPv4 Configuration Type to None - Save - Apply
b) Go to Interfaces: Virtual IPs: Settings - Click on the + - Mode Other - Click Advanced - Select Mullvad Interface - Add IP/32 and Gateway - Save - Apply - works but appears to be redundant. It's not needed after all as per Franco's post below, and I've been able to confirm that.
c) Reboot OPNsense
================================================
The final straw in my case was that after migrating to the VIP, the road warrior WG instance needed the NAT on the Mullvad interface -- yet it wasn't necessary on the previous configuration.
Still not sure why the VIP is necessary in these cases. The instance tunnel address is exactly the same setting?
You're right - appears to be just fine without the VIPs. Rebooted twice to make sure it wasn't a fluke and it comes up as expected on both GWs
Good. So instead of going through hoops for automatic NAT set WireGuard straight, assign interface for gateway, add NAT outbound and done?
It shouldn't be more work?
Cheers,
Franco
Hello everyone....
I was wondering if someone could give me a hand with this.
I have tried for days to get this to work with the latest version 23.7.9 and for the life of me I can not get it working.
Does anyone have a step by step guide?
Thanks and much appreciate any help I can get.
Dean
Quote from: dolivas27 on November 28, 2023, 09:05:30 AM
Hello everyone....
I was wondering if someone could give me a hand with this.
I have tried for days to get this to work with the latest version 23.7.9 and for the life of me I can not get it working.
Does anyone have a step by step guide?
Thanks and much appreciate any help I can get.
Dean
Did you happen to find something?
Nope and no replies so I fired up a pfSense and it work right the first time.
Maybe another time I will give OPNsense another try but right now things need to be fixed.
Could someone please write a guide? I cannot get it to work either...
Christian McDonald has youtube video's on this.
i can setup connection from scratch in less than 15 minutes
https://www.youtube.com/watch?v=wYe7FzZ_0X8
mullvads website even has directions
Quote from: DEC670airp414user on December 04, 2023, 06:29:48 PM
Christian McDonald has youtube video's on this.
i can setup connection from scratch in less than 15 minutes
https://www.youtube.com/watch?v=wYe7FzZ_0X8
mullvads website even has directions
Yep He sure does and it's on pfSense and yep I had it running in 5 minutes..... SMH
I'm close enough with this.
I have already pfsense wireguard to pcs/android, opnsense wireguard to pcs/android and I also happen to understand a little bit more of wireguard (peers, instances, ports, nat, rules needed for this) with this test. I will try to connect to opnsense this weekend I'll let you guys know the end of this history.
maybe someone having the issue can try this
when creating the interface. leave ip4/ and ip6 as none.
at the bottom check Dynamic gateway policy.
when doing policy routing. it will create a gateway to monitor. and choosing for outbound NAT.
this is probably why I never had the issue as I figure out a version back or so it created the gateway unexpectedly
can't test this with Mullvad as I do not have an account. but this works with 2 other "providers"
I did not do it when I was able to connect from another location to my home.
However when I came back to my home I was not able to browse over internet so I deleted every rule I did (the weird thing is that I was able to connect to wireguard from another location and ping local network).
When I tried to set up again wireguard it just doesn't work so I'll be trying this days again however I was able to connect to wireguard from another location without a problem before so there is some kind of success in it
This might be off topic. However, I want to share my experience. After numerous attempts and endless searches for solutions, I caved in and reluctantly decided to give pfSense a try. I got everything to work using this guide: https://blog.networkprofile.org/mullvad-vpn-with-wireguard-in-pfsense-setup-guide/
So I have wireguard working after a few days.
Weird thing is that if you setup wrongly (because I know I did in a some tests) your wireguard probably it's stuck if you messed up with it.
Mine was stuck at "ROUTING: not a valid interface gateway address opnsense" even after uninstalling and installing the plugin.
So I reverted to default and setup up it from start now it's working fine.
EDIT: I didn't applied any of the recommended settings from youtube and posts that you need to change nat, alias, etc, I just did what was needed per se. Just start with settings from instance, then peers, and last enable wireguard.
Screenshots:
https://drive.google.com/drive/folders/1b40jr_BoD7ReOldYwtO1kWXb19YbKleP?usp=sharing
TLDR:
Tunnel Address 192.168.105.0/24 and then for this subnet I assigned each peer over here, ie personal peer1: allowed ip 192.168.105.1/32 and in their config I just use the same IP.
allow traffic port 51820 of wan and allow all traffic from wireguard to any network
Config example after the default one (interface privatekey):
.....
Address = 192.168.105.1/32
DNS = 172.16.100.1(localdnsip), 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = publickeyfrominstance
AllowedIPs = 172.16.100.0/24 (subnet from the network I want to get access /24)
Endpoint = myddns.com:51820 public domain or ddns:51820
Best Regards.
well
i do not want my entire network to go over a vpn "provider" that is why i would never use the default setup
creating alias and the gateway setup I posted a few posts above. will allow policy based routing properly to select devices aka alias.
Quote from: franco on October 19, 2023, 08:27:05 PM
Good. So instead of going through hoops for automatic NAT set WireGuard straight, assign interface for gateway, add NAT outbound and done?
It shouldn't be more work?
Cheers,
Franco
I can confirm that removing the static IPv4 config from tunnel interfaces "just works". VIPs also aren't needed.
However, with tunnel interfaces not being statically configured, I cannot use them as
Outgoing Network Interface for Unbound DNS anymore. Using VIPs didn't do the trick. The Web GUI docs for valid outgoing interfaces state:
QuoteUtilize different network interfaces that Unbound will use to send queries to authoritative servers and receive their replies. By default all interfaces are used. Note that setting explicit outgoing interfaces only works when they are statically configured.
Does that mean this option is incompatible with tunnel interfaces going forward? Is that an issue I should raise on GitHub?
Set tunnel address in instance accordingly? Unbound still needs an address to bind to.
Cheers,
Franco