Hi everyone,
So it looks like the xml database frontend for OPNSense puts in place an artificial limitation that is unnecessary. WireGuard itself can accept multiple comma separated "Allowed IP" address ranges, but the web GUI frontend rejects multiple address ranges with the error message "Please specify a valid network segment or IP address."
But let me back up a little bit and explain why I need this.
Background:
I am a little bit of a privacy absolutist. I hate that my ISP is harvesting data about me based on my internet traffic. Several years ago Verizon was caught inserting so called "Super cookies" or "Zombie cookies" into every IP packet leaving their customers networks. Essentially they added a unique identifier to each customer into the IP packet on their side of the network, so users could not do anything about it.
Amid fierce criticism, they eventually walked this back, but given how tech companies have a practice of overstepping, walking things back, then waiting for the controversy to die down before trying again (possibly in a slightly different way) and hoping there isn't as much pushback the next time, I have absolutely zero trust that are not up to the same tricks again.
I want to be able to eliminate their ability to track me in any way I can.
To that end I use a trusted VPN partner to help anonymize my traffic. I know this means I have to trust the VPN partner, but in this case I do.
So, 100% of all traffic that leaves my network goes out via wg0 to my trusted WireGuard VPN.
The standard configuration here is to set "AllowedIP's" to "0.0.0.0/0" in order to allow all traffic to traverse this encapsulated link.
The Problem:
Initially I used the setup above to protect my home network, and the VPN providers app to protect my phone traffic when outside the house. It worked great for years, until suddenly it didn't. Not trusting my phone providers cloud service for any backups (again, due to privacy considerations) I have a script that syncs my phone to my own NAS on a regular time interval.
Recently, and suddenly this stopped working properly. In all likelihood this is a combination of the fact that I am double encapsulated when my phone connects to my local network via wifi, and an MTU problem where something in my upstream path recently changed causing VPN packets to be too large and run into MTU limits upstream.
So, I figured, I'll just stop using the VPN providers app on my phone, and instead set up my own Wireguard endpoint on my own network allowing my phone to connect to my own network remotely, and never be double encapsulated.
This requires an OPNSense setup with two separate WireGuard Instances. wg0 for the LAN traffic to reach the VPN provider, and wg1 as the server allowing my phone to connect to it.
The issue is that "AllowedIP's" cannot overlap. If you set AllowedIP's to 0.0.0.0/0 on wg0, this covers ALL IP addresses, so if you add any allowed IP's at all in wg1, then there is an overlap, and thus a conflict, and despite me checking the "disable routes" box on both wg0 and wg1, any time I enable wg1, traffic becomes horrendously slow and unreliable on wg0 due to the conflict, likely some sort of kernel routing issue.
If wg0 has allowed IP's as anything other than 0.0.0.0/0 it does not work. This is because the way they have their network set up, you need BOTH the endpoint of the remote WireGuard server AND the gateway on their network in the allowed IP address range, and since OPNSense has data validation that only allows one value in that field, there is no other way I can design it to cover both than to allow everything which is what you do when you set 0.0.0.0/0.
If I were writing the wireguard config file manually, I could just comma separate two strings as follows:
<endpoint IP>/32, <VPN gateway IP>/32
This allows me to set a separate AllowedIP range for wg1, that does not trample on the defined address ranges for wg0, and should work.
...but the OPNSense configuration does not allow this due to incorrect input data validation. I can still set it manually by editing /usr/local/etc/wireguard/wg0.conf, but the way OPNSense handles its config xml's, this is not persistent across reboots, and really feels like a hack. I might be able to force the issue by editing the main OPNSense xml config file manually, but I am not convinced that won't break something else, and also have persistence issues.
Another alternative to solve this would be to configure two separate peers using the identical public key, one that includes only the endpoint address in it's allowedIP's range, and another that includes only the VPN gateway in its AllowedIP address ranges. I am told this ought to work with vanilla WireGuard, but again I am foiled by input validation, as if I try to set up a second peer with the same public key, I get an error message that "public keys must be unique" and it won't let me save it.
Again, if I solve it this way, I could edit /usr/local/etc/wireguard/wg0.conf and do it manually, but it would have all the same issues associated with it (persistance/reliability) as the previous manual edit.
Here's the thing, I don't feel like my setup is that uncommon. There must be plenty of people out there who need more than one wireguard instance, and have issues creating allowedIP address ranges that don't conflict.
Questions:
1.) Am I missing something? Is there another obvious way of doing this I just am not seeing or haven't thought of?
2.) It feels like this is a rather crucial aspect of WireGuard that is just not implemented by OPNSense. Either the ability to add multiple comma separated address ranges to the "AllowedIP's" field or allowing multiple peers with the same public key should solve my problem, both of which can be done with WireGuard using manual configuration, but the OPNSense config input validation gets in the way.
I can understand why these input validation restrictions might be there, as if someone who is less knowledgeable mistakenly messes up the Allowed IP's field or creates multiple peers with the same public key it can cause all sorts of problems, but maybe these should be made available somehow under advanced settings to those of us who know a little bit more?
3.) Not sure if this is a "bug" but it might be (since I cannot use the full features of WireGuard) but at the very lest it is a feature request. How can I go about reporting it to get this resolved?
...because if I can't get this resolved, I'll have to spin up a separate VM (or maybe a container) that has its own WireGuard configuration just for the second WireGuard Instance, and that feels really dumb and wasteful.
I appreciate anyone's input.
You wrote quite an essay there.
The model comma separates values automatically. Just enter a range without comma, press tab, enter the next range without comma, and so on.
Quote from: Monviech (Cedrik) on December 08, 2025, 09:27:45 PMYou wrote quite an essay there.
The model comma separates values automatically. Just enter a range without comma, press tab, enter the next range without comma, and so on.
Thank you for your response.
You are correct. I was mistaken.
I must have gone too fast and just used a comma to separate the IP fields, causing the frontend to reject it. If I do not use a comma it allows me to save the configuration.
Sadly, it still does not work. I had assumed that my problems were due to an "Allowed IP's" overlap, but it turns out that this is only a problem within the same instance. I have two separate instances, so this should not be an issue.
Something else weird is going on.
I'll be humming along with wg0 working just fine connected to my external server and routing all traffic through it. Then as soon as I click "enable" and "apply" on wg1, a wireguard server for my roadwarrioir hpone setup, wg0 shits a brick.
Connectivity becomes intermittent and slow, and things just fall apart.
The funny part is wg1 works just fine. My phone can connect and access both my internal LAN and the external internet exiting via wg0.
I don't think it is an MTU issue, as the two tunnels are independent of each other, so there is no double encapsulation. With routing disabled in the instance, it also should not be a routing issue.
But I can't for the life of my figure out why enabling wg1 harms wg0.
Any suggestions?
"Disable Route
Actually, I think I solved it.
I don't know how this happened, but I looked at my outbound NAT rules under Firewall -> NAT -> Outbound.
There was only one rule here, from source any to destination *.
The issue? It was assigned to the "WireGuard Group". Presumably this worked in the past because I only had the one WireGuard interface, but once I added a second wireguard interface, this group now automatically included all WireGuard interfaces, so this outbound NAT rule now applied to all wireguard interfaces.
The second wireguard interface I was using to connect my phone to my LAN does not need (and probably should not have) outbound NAT rules, so I changed the interface for this rule from the WireGuard Group to applying only to the network associated with WG0 and now I can enable WG1 without it hosing wg0.
I hope this helps someone else. I have wasted hours troubleshooting this.
I'm not sure how it happened, if it was some weird default setting, or if I accidentally created it through some sort of typo during my initial wireguard setup, but at least now it is resolved.