Messages

I complained earlier about the "6 unbound failures a day". 

Just wanted to say that regressing to the previous version of unbound appears to have solved the problem.

Came here with this problem... unbound had been crashing roughly 6 times a day since the update.

I tried the unbound regression, but it may have not solved the problem as unbound fell over again about an hour later.

Will keep monitoring this thread and I'll be watching to see if the same problem keeps repeating.

Have the same issue with Rogers in Canada.

Relevant thread here: https://forum.opnsense.org/index.php?topic=11011.0
Relevant ticket here: https://github.com/opnsense/core/issues/2544

My IPv6 works fine (in fact, as someone moving over from pfsense, it was easier to configure and seems to acquire ipv6 addresses more reliably than pfsense).

I'll go through that checklist and see if I can get it working fine, but yes, as IPv6 become more ubiquitous, surely having total feature parity with IPv4 should be an objective, including the very elegant way that IPv4 transparent proxy configuration has been set-up.

One of the big differentiators I find with OPNSense vs.pfsense is that much of the management has been simplified, particularly wrt package configuration.   This would be a great way to continue investing in that OPNS way of doing things.

I'll report back after I have a few moments to try the manual approach.

I'm trying to enable an IPv6 Transparent proxy and found this thread.

Both my original attempt to use an ::1 loopback address and this thread's suggestion to use a link-local interface doesn't seem to work.

Is this the latest and greatest on the issue?

I think I discovered the problem.

I had "enable Static ARP" on, which I interpreted as "Sure, I'd like to also use Static ARP in the future".

But it seems that that means only static ARP, and so none of my traffic was going anywhere.

Everything going MUCH more smoothly now, and in fact I found the overall configuration process was more intuitive than pfsense. 

Well, it was suddenly fixed after I did a lot of fiddling... if I figure out what did it, I'll report back, but I basically did the following:

1. Disabled hardware handing of VPNs
2. Opened up firewall rules to change everything from NETWORKNAME net *, to , * *
3. Replaced automatic NAT with hybrid NAT and adding manual NAT rules for all subnets to WAN

I'll eventually undo most of those and see if it breaks again.

Yes, it seems like the failure should be at the Firewall rules level, but I think I've ruled that out.

As I'm doing my first ever OPNSense set-up and am just trying to get connectivity established, my Firewall rules are wide open for everyone except WAN.

Using your network example, it would be:

QPVLAN IPv4 * *
QPVLAN IPv6 * *

Basically, it's 'any to any' for all protocols.

So is there anything about VLAN tagging that prevents it from reaching layer 3 rules??

[I can't seem to get the VLAN tagged traffic routed.]

This may be a stupid question, but for the life of me I can't figure out how to solve this in the OPNSense world.

So I had a pfsense router that used 802.11 tagged VLANs to route traffic across different SSIDs.

I've migrated this to OPNSense and have it *almost* entirely working, except that I can't seem to get the VLAN tagged traffic routed.

I have rules defined that should all all traffic to be routed everywhere, and it's working fine for untagged traffic coming from the Unifi AP.

So, for example,

Working

WAN <-> OPNSense <-> Uniifi AP (but untagged traffic)

Not working

WAN <-> OPNSense <-> Unifii AP SSID indicated with tagged VLAN

Strangely, all of the devices on VLANs are able to get correct IP addresses allocated from the VLAN subnet address range from the OPNSense DHCP server, but they even can't ping their own subnet gateway, much less get routed to the internet.

I think pfsense got around this by having a section where you had to tag traffic as "0,2t", but I don't know how to do this in OPNSense.

Any suggestions appreciated.