Messages

Hello, I have a bit of a weird problem which seems to be related to LAGG.

Context:
My homelab looks a bit like this:
Modem -> External Router -> Unifi switch -> Internal Router (OPNsense running on Topton) -> Internal devices
Apart from Modem and External Router the other devices are on a UPS with surge protection.

The other day there was a thunderstorm and I thought to disconnect the UPS for a while but not the Modem and the External Router. When the storm passed and I turned the devices on, almost nothing was working.

After some debugging, I figured out that the PoE ports of the Unifi switch (4/8) had had some issue (possibly fried) and I could only plug a cable to 0 or 1 ports at a time (I could plug in a cable if I used a USB to Ethernet adapter. Plugging a cable straight into it caused the Unifi switch to shut down until I removed it which it started its reboot sequence. Luckily, Unifi have agreed to RMA this)

I ordered a cheaper D-Link switch until they replace my Unifi switch, set up the VLAN's as before and again some stuff did not work as it should. Cue more debugging and I now figure out that WAN in OPNsense does not acquire an IP (It is DHCP statically allocated according to the guide here). I should say here that my WAN port was a LAGG of igc0 and igc1 with VLAN tag 10 and that it was working without a hitch for a long time. .

Now my first thought was that this port got fried too but I start trying a few things and figure out that if I remove the LAGG (LACP) and create a VLAN for each port separately (igc0.10, igc1.10) it works without a problem and the WAN does get an IP.
After tinkering for a while I restored to the config before my tinkering and again the same issue arose.

I think I was on at least 24.7 and I don't think I had updated for a few weeks so I am thinking 2 things:
1) Did anything change with regards to LAGG during the past few releases which would cause it to not be able to acquire an IP and I only realized because I turned off the router which usually runs 24/7?
2) Has any hardware been fried and now the 2 ports can't aggregate together?

For 1, I checked the changelogs and didn't see anything related
For 2, it's okay I did not really need the link aggregation, it was more as a proof of concept.

Any help is welcome and thank you for your time.

Hello,
I had a pull request accepted the other day and the website hasn't been updated yet. Out of curiosity, when does this happen?
Also how come there isn't a CI hook to automatically deploy it?
Contemplating if I should add such a thing.

I recently used the guide for selective routing to setup ProtonVPN as an external endpoint.
I think you are in a good path if your gateway is online and you can see traffic on the VPN diagnostics page.
A few common gotchas could be not checking Inverted when you should or skipping checking a rule as Quick.
If you want someone to help you would have to share your firewall rules.

For my rules in a nutshell, I allow nonRFC 1918 traffic in the bottom of my "LAN" firewall rules and then specifically allow any traffic that I need to allow. Then on top of that I have the rules to route traffic from specific hosts (the Alias defined in the guide) through the VPN gateway + the Floating rule and the Outbound NAT suggested in the guide. I then had to experiment a bit to get the DNS leaks sorted but all in all pretty straightforward.
There was a small gotcha with the private and public keys for Proton but if you say that Wireguard works fine then that shouldn't be it.

Hello,

I skimmed through your post because it is super long and does not include quite a few details.
The first thing that pops out is that you haven't configured your Wireguard correctly so anything else is pointless until you fix this.
In VPN -> Wireguard -> Diagnostics you should be able to see value other than 0 and in the range of KB in both received and sent.
Sometimes scarce bytes escape into it so if you see the sent bytes increase to a few KB and the received bytes are 148 then it is possible that you still haven't configured it well.

So I am working on a slightly better solution that consists of having a separate DNS server for the other hosts.
I think that the problem is that if Pihole is a forwarding DNS server then the packets are going to be in 2 parts:
1. from Pihole to OPNsense Unbound DNS and
2. from Unbound DNS to external DNS servers.

If both VPN and non-VPN hosts use Pihole as a DNS it is impossible to create a rule that will distinguish between those two in order to route them to different gateways because the outgoing packets in both these cases will have correspondingly the same source and destination.
Maybe you could set a tag but I am not too familiar with them.

What I am thinking is that the VPN hosts use a Pihole+Unbound DNS server on a Raspberry Pi. In this case the source would be the Raspberry Pi's local address and you could easily create a rule to send this traffic through the ProtonVPN gateway whilst all other traffic would be going through the other Pihole+OPNsense's Unbound DNS.

So I found a solution to plug the DNS leak for the VPN hosts but there are some caveats.
If you add a NAT outbound rule as specified below then the VPN hosts will get DNS through the VPN but non-VPN hosts will get DNS through the VPN too. Also I am not sure what will happen if the VPN is unavailable (i.e. if the killswitch will work correctly)
NAT outbound rule
Interface: WAN (the default WAN)
TCP/IP: IPv4
Protocol: Any
Source invert: Unchecked
Source address: WAN address
Source port: Any
Destination invert: Checked
Destination address: RFC1918 (Alias with all the local subnets)
Destination port: DNS
Translation/target: VPN WAN

Hello fellow network enthusiasts,

I followed the guide to setup external VPN (Proton) and now I am trying to address DNS leaks for my setup.

My goal is to setup the following.

All hosts (VPN + nonVPN) get a PiHole DNS server through DHCP.
PiHole DNS forwards to Unbound DNS.
For nonVPN hosts:
Route DNS traffic to Quad9 DoT server

For VPN hosts:
a) Unbound traffic goes through the Wireguard interface to ProtonVPN server (DNS server is provided through the wireguard interface)
b) If the VPN endpoint is down, route DNS traffic to Quad9 DoT server

If I have understood the use cases correctly they should look like this:
nonVPN Host -> Pihole -> Unbound DNS -> Quad9 DoT
VPN working:
VPN host -> Pihole -> Unbound DNS -> WG Interface -> ProtonVPN endpoint
VPN not working:
VPN host -> Pihole -> Unbound DNS -> Quad9 DoT

Can someone help me make the necessary adjustments to the guide so that this works?

Hello!
I am having the same problem.
Did you find a way to update the URL?
Thanks!

Hello,
No and yes. Basically someone added support for njalla so no need to have a custom URL anymore.
Basically njalla works for me now.

Can someone maybe add a summary of the firewall rules they had to add? I think I have completed steps 1-7 correctly and 9-10 but not sure about 8.
In my LAN rules I had a rule allowing everything !RFC1918 and then punched holes through that rule to allow some packets to go around the private subnets. e.g. allow LAN net to be able to access local DNS etc.

But now adding another rule I am not sure where to put it exactly

Same issue here with dyndns and njalla.

But it seems like the problem has been fixed upstream and now we only have to wait until it makes its way to a release.

I don't know if it has been intentionally dropped but maybe the force update button would be nice to have in ddclient plugin as well for situations like these to test that the update has been done manually.

The rules are effective immediately. However established connections that e.g. were allowed and are now supposed to be denied, will continue to work because OPNsense is a stateful firewall. You would need to clear the state table in this case.

Changing rules from block to allow should be applied immediately, changing from allow to block requires resetting the states as allowed traffic remains allowed until the states are expired or killed.

Thank you very much for the helpful explanations.

As per the title.
I see videos where they change a FW rule and then proceed to see its effects immediately, however my experience hasn't been the same. I normally change the rules press apply changes and it doesn't seem to have an effect before some time passes.
How long does it take before the changes are actually effective?

Thanks for any help.
S

Hello and happy holidays,
So I want to do some password hygiene before the end of the year and I am trying to update my forum password.
I can log in ok to my account with a long password (>200 chars) but when I try to change the password in Profile -> Account Settings it complains that the current password is not correct.

I did a couple of experiments and verified that it works with 50 chars but not with 99.
Now I am not in the mood for doing a binary search to figure out what the correct max password limit is so can you please enlighten me?

I find it extremely annoying when the limits are not explicitly stated when you provide the password for the first time but it truncates it in some subsequent steps and causes weird discrepancies down the road.

Yeah, I figured it out. And to give credit wherever it's due I think I saw it in this HomeNetworkGuy article.
This may be a workaround but it will serve me for now.
So to solve go to Firewall ->Settings -> Advanced -> Static route filtering and tick/enable Bypass firewall rules for traffic on the same interface.

Hello,

I am trying to use a RPi with containers connected in an IPVLAN network.
For those that may not know about this in IPVLAN the host (RPi in this case) acts as a router and the containers are in subnets within the host which by default are not connected to anything.
Therefore I need to tell OPNSense to know how to get to them.

The first thing that I have tried is to use Static Routes even though there is a warning that you should use this with external routers (mine is in the same subnet).
This mainly works apart from an issue with SSH. When SSH'ing into the container the connection will drop after 30 seconds if FW Optimizations are set to normal or 15 minutes if they are set to conservative. You can notice that into the Live View because the rule Default Deny/state violation rule will fire. Another way is to go to Diagnostics -> Sessions and notice the expiration value.
As far as I understand this is caused  because the SSH connection does not send anything to keep alive the connection and only works so far as its original expiration. I have tried tampering with TCPKeepAlive, ServerAliveInterval options in the SSH client side and server side but nothing seems to change it.

What I would like to try is to replicate the static route with a firewall rule in hopes that this will behave better and will allow the SSH connection to understand that it is still alive but I am not sure how to set that up.
I tried a pass FW rule with source LAN net and destination the subnet in IPVLAN and to setup the RPi as a gateway but this does not work.

Has anyone had the same problem? Can you advise on what I am missing?