Messages

No, unfortunately doing so would not comply with the IPv6 spec requiring all networks to be at least /64 (and OPNsense does not allow you to violate that).

Something that worked for me (Comcast) is using a prefix hint. On your WAN interface, check the Send IPv6 prefix hint option and then try setting 62 as your delegation size (4 usable prefixes). Apply the changes and wait. I ended up rebooting my firewall and got no IPv6 at all, I figured it wasn't working, but it was late, so I went to bed planning to set it back in the morning. I woke up to find the requested /62 allocation! Guessing Comcast's DHCPv6 lease had to timeout before it would grant a different one.

PS: I would give the prefix hint a try despite what you were told by Robbers. Comcast officially says the same thing, only one /64 for residential customers, but it worked for me and others too. Plus, I kind of doubt the person you talked to even understood what an IPv6 allocation was, he probably just said no to get you off the phone  :)

The more I think about this, if you really want to turn an unRaid server into a switch, you should look at defining a bridge interface on the unRaid OS itself (not supported with the GUI but should be possible with a Linux script running at a startup). This is the kind of thing that will work best running directly on real hardware, not a VM.

OPNsense is honestly not designed to be a switch, so you may not get great performance even on physical, virtual will be even more of a challenge. I can also tell you from my own experience that running an OPNsense VM on unRaid, using vNICs had unusable performance. My understanding is that was some kind of conflict with the version of FreeBSD currently used by OPNsesne running on KVM, so it's possible that issue has been fixed.

I ended up using SR-VOI to physically assign the network ports to the VM. If that is possible for your configuration, I highly encourage you to do that. If not, see if you can completely assign the PCIe/USB device to the VM. Even if the above vNIC issue has been fixed, hardware assignment will result in the best possible performance.

Now to the OPNsense question. To make OPNsense a switch, don't assign anything to the WAN or LAN interfaces, just leave them unassigned. That simplifies issues with default services running on those interfaces. Assign all your hardware NICs (or vNICs) to OPT interfaces, then create a bridge interface in OPNsense that uses all those OPT interfaces.

Having said all of this, I don't think you realize how much CPU power would be needed for what you are trying to do. Whatever your need is, it would likely be much better served with an <$80 gigabit switch. If your goal is to use faster than gigabit interfaces, then it is unlikely you will ever get that level of performance on an OPNsense bridge without burning crazy amounts of CPU cycles.

I haven't done a lot of OPNsense fresh installs, but my memory is that the default setup should allow for internet access via NAT from LAN to WAN.

First question, is OPNsense getting isn't WAN IP from your ISP's DHCP? If so, then it looks like that passthrough NIC is working. If you had to do a manual configuration, then it may not be working as expected. Is that a hardware passthrough, or a bridged virtual NIC? If its a bridge, then make sure that Proxmox has no IP address configured on interface. If it is hardware passthrough, then Proxmox shouldn't see the interface at all while the VM is running, but you still want to ensure it doesn't have IP address while the VM is stopped.

For troubleshooting purposes, I would create firewall rules on all interfaces to allow all ICMP. Once you do that, trying pinging the WAN IP address from a LAN client. The results should point you to the next troubleshooting step.

If it replies, but you still cannot ping the public internet, that could be a firewall rule, routing table, or NAT configuration issue. Ping 1.1.1.1 and trace the packets on the firewall and see what is happening to them. If it shows they are being forwarded to the WAN gateway, then you have some kind of issue on your vNIC's bridging configuration. If it shows they are being dropped, then its an issue in your OPNsense config.

If the firewall replies with an error, then that is very clearly an OPNsense configuration issue, likely NAT or routing table.

If the ping requests time-out, check to ensure the OPNsense LAN IP is set as the client's default gateway. If it is, then check the firewall logs to see if it received those packets and if so, what it did with them.

You might try shutting down that VM and trying a fresh one with default configuration so see if the results are the same.

I don't see a way to do that with the included DHCP server. Just set DNS to 192.0.2.1 (RFC 1166 unusable address).

Considering your hosts will have no gateway, they will instantly see no possible route to that address, which should cause connection attempts to instantly fail without a single packet ever leaving the NIC.

That service should use the DNS configuration defined in System --> Settings --> General.
If you want to ensure the firewall resolves addresses the same way your internal clients do, then uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN" and clear any public DNS servers listed there.

If using a resolver service like Dnsmasq DNS or Unbound DNS, make sure to configure upstream public DNS servers there instead, as those services were probably formerly getting that information from general settings.

If using another local host for DNS, then make sure you specify that host's IP in the General settings page (127.0.0.1 is assumed if nothing is provided).

EDIT: The OPNsense implementation of Dnsmasq doesn't seem to allow you to manually configure DNS forwarder addresses. I switched to Unbound DNS for that exact reason.

I am not sure why turning IPv6 on and back off would have any effect on IPv4 traffic. I am going to take a guess that this isn't a OPNsense issue considering it appears to be OS specific. I would first make sure that IPv6 is disabled on all firewall interfaces, not just the WAN interface. If connecting by hostname, make sure there is no chance of an IPv6 address resolution.

You can verify packets are passing the firewall by looking at the Live View under Firewall, you will want to create filter rules otherwise they will fly past faster than you can read them.

On the Windows side, my best guess is that the Windows firewall might be incorrectly classifying traffic crossing VLANs as edge transversal traffic, which it nearly always blocks by default. Verify this by turning the Windows firewall off on one host and seeing if that corrects the issue. If so, then you know that is where to focus.

If all else fails, reboot the switch and firewall...you shouldn't have to do that, but depending on how your trunk port is being negotiated, maybe something went wrong there (seems unlikely considering the Linux traffic is working). A switch reboot also forces all the hosts to reinitiate their IP stack, which isn't a bad thing given the odd Windows behavior.

Keep in mind that "Magic Packet" can be sent directly as a layer-2 frame which cannot be routed, or a UDP:9 (or sometimes 7) packet which can.

It is important to understand how the magic packet is being sent. Most apps I have seen use UDP, but to be sure, start WireShart on the same subnet and filter for "WOL." Send the packet locally on that same network and see what shows up. If the destination is an IP address, then it is using UDP, if the destination is a mac-address, then it is not, and you would need to find another way to send the packet in order for it to be routable.

IPv6 does this by design, but with IPv4 you have to document it yourself.

One bit of advice when assigning static IP addresses to hosts, try to think of them as base-2 numbers, not base-10 numbers. What I mean, is don't do something like "Server are .20-.30, Printers are .50-.70." Instead use numbers like "Servers are .16-.31, Printers are .64-.95." That way, even if you never plan to divide the network up into vlans, you can still write rules based on the type of devices, so servers would be 10.0.0.16/28 and printers are 10.0.0.64/27. If you do think you might want to create VLANs at some point, avoid using the first, second and last addresses in each range as they would need to be the network, gateway and broadcast addresses respectively on a vlan.

I agree with the 1st reply, what you are asking for it not possible with any firewall. Hosts on the same network segment will be able to reach each other on layer-2 (your switch or access point) without touching the firewall.

If you are trying to create a small number of segments, that is exactly what VLANs are meant to accomplish. If you are trying to create a scenario where every client can only reach the firewall (and whatever its rules allow), then that would require some more thought.

Some WiFi systems have an option to prevent client-to-client communication, but of course that only helps for wireless. Fully managed switches can accomplish this, but it doesn't come naturally for them, so expect a pretty complex configuration.

A poor man's approach would be to run OpenVPN within your own network. You would create an OpenVPN server on your LAN interface, create firewall rules that block everything on the LAN interface except for OpenVPN traffic (to force the use of OpenVPN, this doesn't actually stop host-to-host), then configure the VPN client configs to not allow local LAN traffic and block traffic even if VPN is disconnected. This isn't true security, if any two clients simply closed OpenVPN they would then be able to communicate, but you can at least be sure that in such a state they would lose their internet access.

That sounds like a perfect scenario for a bridge. The bridge will not only share DHCP between the network segments, but fully join them so that traffic can pass from hosts on the gigabit switch to 2.5G hosts.

One thing to keep in mind is that a firewall does not make a great network bridge. If you have any meaningful amount of host-to-host traffic on your network, you may see increased CPU usage on your firewall.

Give it a try and see what happens. If you see high CPU usage in OPNsense or poor host-to-host performance, then you might want to consider adding a 2.5 (or faster) switch to your network so that the firewall does not need to act as a bridge.

My guess is that the magic packet is failing to be forwarded to a specific IP address because an offline system doesn't have its IP stack running, meaning it can't respond to ARP requests. You typically get around this issue by sending the packet to the broadcast address (192.168.1.255) instead of the actual IP. That should blast the packet to all systems, but because the magic packet contains a target mac address, will only wake the desired system.

That is how it should work, however I am running into a similar issue where OPNsense doesn't seem to honor broadcast addresses as expected. In my case, I am not using NAT, but the idea is the same. I'm curious if port forwarding to the broadcast address works, please let me know.

What is the goal of having 1 DHCP instance on two interfaces? Do the two interfaces represent different segments of the same network? If so, you can create a bridge interface and assign DHCP to the bridge.

I am trying to send WoL packets from one network to another. Due to the fact that offline clients can't respond to ARP requests, this is typically done by sending to the subnet's broadcast address.

For some reason, OPNsense logs show the forwarded packet, but doesn't appear to send it. Logs show the packet coming in one interface, passing the rules, and going out the other, but a device running WireShark directly connected to the LAN interface does not show the packet at all.

Is there some setting that is preventing packets from being forwarded to broadcast addresses? I know I could setup a broadcast relay, but for my use case, being able to send a unicast packet to the remote subnet's broadcast address works best for me.