Messages

Seems this is fixed in 21.7.3, I made no changes and just happened to notice the VPN lin k was back up after upgrading.

So does dns whitelisting require using RegEx? the help text says "You can use regular expressions" not you must.

I am having the same issue, its a "backup OOB" VPN so wasn't noticed, but I see in the logs

Code Select Expand

2021-08-22T22:44:11 openvpn[17914] Use --help for more information.
2021-08-22T22:44:11 openvpn[17914] Options error: --client-config-dir/--ccd-exclusive requires --mode server
2021-08-22T22:44:11 openvpn[17914] Cipher negotiation is disabled since neither P2MP client nor server mode is enabled

So for your first post, was "All" not set for "Outgoing Network Interfaces"? All is the default and should work fine.

With this plugin installed, do the contents of the box get included in a Config file backup of the system or no?

By default i believe GIF interfaces on OPNsense are 1280mtu, but you can go to your Tunnel interface and set the MTU of that assigned interface to 1480 (if you have a WAN MTU of 1500, otherwise WAN MTU - 20 = Tunnel MTU).

Then you can goto the HE Tunnel broker site and confirm the MTU for that tunnel is set 1480 there as well, though I think it is by default.

Then if you had to set the MTU of the tunnel interface to less then 1480, then (Tunnel Interface MTU) - 60 = (Wireguard MTU), note this must be set on both Wireguard Clients/server.

Use hostoveride via the DNS server to resolve a domain name to the Local IP.

I wanted to avoid it, but that's probably the best solution at this point.  Added an override and everything worked immediately inside and outside the network.

Why? Its the best way, why bounce traffic off the router unnecessarily (if on the same subnet), or why use hacks (NAT rewrites and mangels packets, it's a hack, especially hairpin/loopback/reflection)

Host overrides are akin (and basically) split horizon DNS.

Use hostoveride via the DNS server to resolve a domain name to the Local IP.

The packets are arriving at the router, but no TTL expired is occuring because the next hop is on the router, but since the router has no service listening on the UDP ports targeted by traceroute and no firewall is enabled to send back icmp reject, traceroute has no way to know the packets have arrived at any final destination.

No.

Again, if you have a LAN firewall rule (Or whatever interface is incoming for this trace) that has a Gateway set for anything other then default OPNsense will NOt show in the traceroute because the packet bypasses the kernel and a TTL decrement just because of the way the packet with a non default gateway are handled.

This has nothing to do with anything listen on UDP or anything, like that.

If you have Rules on the LAN/Incoming interface that specify/override a gateway OPNsense will not show in a Traceroute.

Make sure the Ethernet port the Windows system is plugged into is not set to receive ANY other VLANs tagged.

Ports plugged into VLAN unaware systems/devices SHOULD NOT be set to tag any additional VLANs, they should ONLY have the "native" VLAN untagged.

and now I'm getting TTL Expired in transit when tracerouting to ipv6.google.com so it's in a routing loop

When you do the trace what hops are showing? Is it just OPNsense over and over? Do you see a hop past OPNsense?

If on you incoming interface, say the LAN interface, you have a rule to force/override the gateway say to point to you GIF/Tunnel interface/Gateway, that will bypass OPNsense routing table, thus the null route.

Are you applying/overriding a gateway on the "incoming interface via firewall rules?

I have a /56 dynamic prefix allocated from my ISP. I've configured 4 VLANs with Track interface and Manual DHCPv6 and Router advertisments. One of those VLANs (i.e. VLAN D) has both DHCPv6 server and RA disabled. RA is set to Managed on the other interfaces.

Windows Hosts on VLAN A are getting an IPv6 address from their own VLAN (Native VLAN, i.e. VLAN A) but they're also getting an IPv6 address and termporary address from VLAN D. These extra IPv6 addresses are not present in DHCPv6 leases and they're not part of the DHCPv6 range set on the interface. Windows Hosts also have the other interfaces as DNS servers.

Make sure the Windows host and any non VLAN aware host are not on ports that send tagged VLAN traffic, those ports for end devices should ONLY have untagged packets for a single VLAN.