Messages

Thanks! I apologize for the late response too. Been busy working on content.

It's funny you mention using my site to help you with pfSense because usually it's the other way around. Many OPNsense users use pfSense documentation since there is not as much documentation available in general than pfSense, part of a the reason I created my website.

Interesting note about hardware incompatibility because I haven't encountered that but I use most Intel NICs but recently I reviewed a unit with 10G Mellanox SFP+ and all I needed to do was manually enable the driver via command line and reboot. Worked perfectly after that. I know that Realtek is an issue with FreeBSD in general.

Thanks! I'm glad you found the information helpful.

As you may have noticed, I haven't written about connecting to external VPN providers using OPNsense as an OpenVPN client. I only wrote about using OPNsense as an OpenVPN server. It is on my todo list to write about how to do external VPN connections, but since I haven't spent much time with the topic yet, I can't really offer a lot of advice at the moment, unfortunately.

I don't know if you need to setup the appropriate outbound NAT rules and/or set your default gateway to be the VPN provider so all traffic goes out the VPN. Since you don't want to use policy based routing, I'm assuming you want all traffic to go through the VPN (and I'm also assuming you don't need policy based routing if you're routing everything through the VPN since you're not routing only certain VLANs through the VPN). These are some areas I'm not clear on yet since I haven't taken the time to learn and try out various VPN connections to external VPN services.

I think the way you are allocating IP address is fine because you have separate ranges for dynamic IPs and the static IP addresses you are setting up in OPNsense.

What I was referring to before is that you can set a static IP address on each individual system manually (such as a Windows PC where you manually configure the static IP address instead of using the default automatic DHCP settings) or you can set static IP addresses in OPNsense via DHCP using the MAC addresses. If you set the static IPs in OPNsense, all of your systems can be left at the default automatic DHCP setting and it will automatically receive the static IP from OPNsense. Either way will work for static IPs as long as you don't overlap IP address ranges since you could run into IP address conflicts.

I think there may be some confusion on using DNS servers to look up IP addresses for domain names and using your own domain name to access your networks.

Either end of your networks can use any DNS servers they like to perform DNS lookups. You do not need to set your upstream DNS servers to the same place where you have your domains registered. You can use Google's DNS of 8.8.8.8 to look up your domain name which is registered through GoDaddy to find the IP address of your networks you are trying to access.

You need to make sure both networks can access an external DNS server like Google, Cloudflare, etc before you can properly resolve the IP addresses you set on your domain name. That means you need to have your VPN configured so that DNS will work for any clients behind the VPN. Verify that both networks can access DNS properly before moving to the next step of troubleshooting.

For your domain name, you just need to set the IP address of the main domain or any subdomains you have created. If your IP address(es) are dynamic, you can use a DDNS client like you suggested to keep them up to date. If you are testing stuff out, you can of course manually set the IPs until you can figure out how to properly configure your DDNS clients.

DNS is one of those things you are better off minimizing the complexity involved because it may very well bite you and make it difficult to troubleshoot what is happening in your networks.

You may want to use the bare minimum DNS first to get things working (such as using the built-in Unbound DNS in OPNsense) rather than Pi-hole. Once you get that working, then you can move over to Pi-hole. I find it easier to get the basic functionality working first and then add one new change at a time until I have everything configured how I want. The reason is that I know for sure which changed broke the configuration and then I can roll back to try again (or try something else).

Do you have static DHCP reservation for devices with static IPs or manually configured on each client? Those clients which you set as a static DHCP reservation in OPNsense will still send a DHCP request because those clients have "automatic DHCP leases" enabled rather than a static IP defined on the client itself. It still has to get the IP address just like dynamic IP assignments except you're telling OPNsense to always hand out the same IP address to the client with a static DHCP reservation configured.

It is normal to see DHCP requests every couple of minutes when you have several clients on your network. I believe the DHCP log page is set to "warnings" by default because that log is spammy due to how often DHCP requests occur on the network.

Sorry for the delay!

There are a few things to note in all those details:

1. DDNS is simply a service that updates the IP address for the A or AAAA records of your domain name registrar. That is all it does. DDNS services are not involved in any DNS lookups -- it simply updates records of where you purchased your domain name. That's how DNS lookups know which IP address to use for particular domains/subdomains.

2. DNS is essentially a chain of servers: your devices will perform a DNS lookup using your local network DNS server (if you are hosting DNS on your local network, such as Pi-hole like you mentioned). If your local DNS doesn't know the answer, the DNS query will be recursively performed until one of the upstream DNS servers knows the answer to the DNS lookup. At the highest level you have DNS root servers. They are the last stop at resolving DNS queries. If it can't resolve the query, then it returns a response that nothing was found for that domain name. Of course there is lots of DNS caching that takes place so that the root servers don't have to be queried as frequently. I'm not a DNS expert so my explanations may be a bit crude or not 100% correct... the important takeaway is that if your local DNS server can't resolve a domain name, it will use an external DNS server that you have configured (your ISP DNS servers or whatever you have configured as the upstream DNS server in Pi-hole.

3. If your router has NAT reflection enabled, you should be able to access your internal server using the external domain name since it will recognize you are trying to access a local IP address. I actually prefer to use split DNS (or split horizon or split brain DNS, it has several names) since I can create a DNS override that allows me to specify my local IP address for a particular host/domain name. This is more efficient than a redirect and it allows you to directly specify where you want to a host/domain to point to.

I hope this helps you get started. Let me know if you have other questions!

If you have the WAN interface set up to use DHCP, clients on your LAN should be able to access the internet since it should use the DNS server of the WAN address and use the WAN interface to get out to the Internet.

One thing you may have to check is to make sure the WAN interface blocks private network addresses since that may block your LAN from accessing the Internet. I don't think consumer routers do that but maybe newer more feature rich consumer routers may do that to potentially improve network security (since if the router is directly connected to the Internet, it should not have any private IP addresses coming from the public Internet).

In OPNsense for example, you have to allow private IP addresses on the WAN interface if you are running behind another router.

Yes, if you use your own consumer grade router, you will have an isolated network.

You will also be double NATed. Double NAT is not a feature that has to be supported by the router. Instead it simply means that router 1 has NAT enabled and router 2 which is plugged into router 1 also has NAT enabled. Any devices plugged into router 2 will be behind 2 NAT firewalls.

For the most part, double NAT will work just fine especially for browsing the Internet or using cloud based services (since they are often designed to allow internal/external access to private networks behind NAT firewalls).

The big problem people always talk about with double NAT is it makes it harder for others to access your devices. That may not sound bad but it can cause issues with gaming or other services where users are trying to connect directly to your system/device. Some users use encrypted tunnels using Cloudflare or other providers in order to access their internal network remotely and securely.

This indeed sounds strange especially since you can download from the Internet faster than you can transfer files between your computers. The speeds should be much greater than that.

From a network perspective, I can't think of any reasons why that would happen, but I did find a page talking about slow file transfers (between 2 disks or over the network) which affects Windows 10/11. There is a long list of items that can cause that. It may be worth checking out to see if this is a Windows 11 problem caused by one or more issues.

I have not personally use IPVLAN in Docker, but after looking at it, I think I would like to learn about it in more detail and write about it since it could be an interesting topic.

From what I gather, using IPVLAN allows you to separate your Docker containers into separate VLANs. If I correctly interpreted what I read on Docker's website, you might not need static routes but instead you should configure the switch port that your Docker server is connected to as a VLAN trunk so that you can use VLAN tags/IDs to isolate traffic on the appropriate VLANs. If your Docker server is plugged directly into OPNsense, you would need to ensure the VLANs are configured on that port on OPNsense.

[What happened]

One of the databases containing Plex user account information was breached. The subset of affected data is emails, usernames, and encrypted passwords. A password reset has been enforced by the Plex security team. Below is the full transcript:

Dear Plex User,

We want you to be aware of an incident involving your Plex account information yesterday. While we believe the actual impact of this incident is limited, we want to ensure you have the right information and tools to keep your account secure.

What happened

Yesterday, we discovered suspicious activity on one of our databases. We immediately began an investigation and it does appear that a third-party was able to access a limited subset of data that includes emails, usernames, and encrypted passwords. Even though all account passwords that could have been accessed were hashed and secured in accordance with best practices, out of an abundance of caution we are requiring all Plex accounts to have their password reset. Rest assured that credit card and other payment data are not stored on our servers at all and were not vulnerable in this incident.

What we're doing

We've already addressed the method that this third-party employed to gain access to the system, and we're doing additional reviews to ensure that the security of all of our systems is further hardened to prevent future incursions. While the account passwords were secured in accordance with best practices, we're requiring all Plex users to reset their password.

What you can do

Long story short, we kindly request that you reset your Plex account password immediately. When doing so, there's a checkbox to "Sign out connected devices after password change." This will additionally sign out all of your devices (including any Plex Media Server you own) and require you to sign back in with your new password. This is a headache, but we recommend doing so for increased security. We have created a support article with step-by-step instructions on how to reset your password here.

We'd also like to remind you that no one at Plex will ever reach out to you to ask for a password or credit card number over email. For further account protection, we also recommend enabling two-factor authentication on your Plex account if you haven't already done so.

Lastly, we sincerely apologize to you for any inconvenience this situation may cause. We take pride in our security system and want to assure you that we are doing everything we can to swiftly remedy this incident and prevent future incidents from occurring. We are all too aware that third-parties will continue to attempt to infiltrate IT infrastructures around the world, and rest assured we at Plex will never be complacent in hardening our security and defenses.

For step-by-step instructions on how to reset your password, visit:
https://support.plex.tv/articles/account-requires-password-reset

Thank you,
The Plex Security Team

Greetings! Germany is my second largest source of visitors!

Thanks for the compliments. I'm glad you found the information useful. It definitely takes time to produce the content. As for your questions:

1. The second rule is used to block all unencrypted DNS requests on port 53 -- both internally and externally. Since access to other networks should typically be restricted already (so you couldn't use DNS servers on other parts of your network unless you specifically allowed it), the second rule is more useful to block requests to external servers such as 8.8.8.8. The first rule is placed before the second rule so that you do not block your only allowed local DNS server (which is often the IP address of the network interface where the device resides). By default Unbound DNS listens on all interfaces so a network with the network address range of 192.168.30.1-192.168.30.254 will have the DNS server address of 192.168.30.1, which is the interface address.

2. I actually used to do just as you have suggested -- block the private networks without using an allow rule which has destination invert checked, but I also had a rule below the block rule to "allow all" so that access to the Internet would work properly. If you block private networks, you have to allow "all other" traffic which requires an allow all rule at the bottom of your rules. I saw examples of these 2 rules in a few places online so I used that for a while, but then once I learned more about firewall rules and saw some examples, I realized that you can combine those 2 rules into a single rule which is more elegant. Instead of "block private networks, allow all other networks (to allow Internet)", the rule in the DMZ guide essentially says "allow access to any network that is not a private network (which is the public Internet addresses").

When you have several local networks, it's easier to block all of the private networks and then add a rule above that to allow access to a specific service like DNS because you are less likely to forget to update a list of networks to block if you decide to add another network. It is a bit of a safeguard since it will keep everything appropriately isolated. If you want to open access, you have be intentional with the firewall updates (it's better to block by default than accidentally leave a hole in your firewall that may go unnoticed until it is exploited).

I hope these explanations help clarify the reason for those firewall rules.

It sounds like the package used by the IPsec VPN uses is vulnerable and will not allow you to use it until you update it. I am not sure if you can update that version without an update provided by OPNsense. The versions that are downloaded from the OPNsense repository will be the version that is shipped with each OPNsense release. You will either have to wait until that is patched or perhaps download it from a different repository. However, I do not know if updating it from another repository will break anything since there might be some integration work that needs to be completed in order for the new version to work properly. I would imagine if there is a vulnerable VPN package that OPNsense would update that quickly or be working on updating it soon.

I personally haven't tried a site-to-site WireGuard VPN with selective routing so I am unable to offer much help but if anyone else who browses the forums has any advice, that would be great.

Yes, it sounds like you have a great understanding! You're welcome. I'm glad you like my posts.

I think what happened is that I mimicked some of the rules I used on my network since I knew they worked properly. Then later I realized I had some unnecessary rules created on my firewall and cleaned them up. However, I didn't think to go back to clean them up on that article. I've had several revisions of my rules on my firewall so sometimes cleanup is necessary! Thanks for pointing that out because I like having accurate information.