Welcome to the Home Network Guy forum!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Home Network Guy

Pages: [1] 2 3 4
Troubleshooting / Re: [OPNSense]Routing for host with IPVLAN network
« on: November 02, 2022, 02:22:59 PM »
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.

Security/Advisories / Plex Media Server Breach
« on: August 24, 2022, 02:48:24 PM »
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:

Thank you,
The Plex Security Team

How-to Discussions / Re: Questions regarding Basic DMZ How-to
« on: April 03, 2022, 04:37:37 PM »
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 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 will have the DNS server address of, 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.

Troubleshooting / Re: OPNsense router strongswan-5.9.4 error (Update)
« on: February 07, 2022, 04:02:14 PM »
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.

Troubleshooting / Re: Wireguard Site-to-site with selective routing
« on: January 10, 2022, 11:08:20 AM »
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.

How-to Discussions / Re: Clarification on Basic DMZ How-to
« on: December 01, 2021, 11:51:45 AM »
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.

How-to Discussions / Re: Clarification on Basic DMZ How-to
« on: November 25, 2021, 11:14:20 PM »
That’s a good catch. I may have made those rules mimic the rules I was using at the time of the writing of the article so I know I had working rules.

Rule 3 is redundant (unless accessing some other service on the DMZ interface that is running on OPNsense).

I need to go back to simplify and clean up those rules. Thanks for the feedback!

Tech Discussions / Re: IPv6 Confirmation
« on: November 12, 2021, 11:19:18 AM »
Sorry I didn't see this sooner. I think sometimes subsequent comments are not always emailed to me to reduce the number of email notifications.

I don't know if the track interface will work behind another firewall unless you can somehow use delegated prefixes from the other router you have on your network. The ISP provided modem/router is not always the most feature rich. They seem to only have the most basic features available for you to manipulate (hence why OPNsense/pfSense is awesome). My guide was written as OPNsense being the main router. When you run OPNsense behind another router, it complicates the set up and you may not have all features available to you or you have to go about configuring them differently because you are now on a network that's behind another network. Having OPNsense as your main top level router enables you do more since it's the main entry point into your network.

I know we have had some discussions on Twitter, but I wanted to reply for others to see.

Tech Discussions / Re: IPv6 Confirmation
« on: October 17, 2021, 04:03:43 PM »
No problem! Please report back since others may be interested in that info. I only have one Android tablet I could test with.

Tech Discussions / Re: IPv6 Confirmation
« on: October 17, 2021, 07:56:29 AM »
Thanks for the info! Does it obtain IPv6 via DHCPv6 or SLAAC? I think it was DHCPv6 support that was lacking in many Android devices (at least in the past when I was reading about it elsewhere on the web). That is why I mentioned enabling “assisted” mode since it will allow both DHCPv6 and SLAAC to assign IPv6 addresses so even the Android devices that don’t support DHCPv6 should still obtain an IPv6 address. I wanted to make sure the guide would work for such devices which means you can’t use DHCPv6 only.

Proposed Network Designs / Re: First wired network - some concerns
« on: October 01, 2021, 06:47:12 AM »
Sounds like you have a good situation for being able to easily cool the room. I don’t think you’ll regret adding ventilation especially if you start adding devices which run a little hotter. Heat builds up easily in an enclosed room.

If you’re running Cat6 for the cameras, you might as well run it for everything. It’s not super expensive and you can run at 10Gbit speeds up to 55m (~180ft). The cameras and PoE would run fine on Cat5e (and everything else) but why not future proof a little bit and use a better quality cable (then you won’t have to redo anything later).

Also if you are running through walls (and between floors which doesn’t apply to you as a 1 story house), you should get riser rated cable since it doesn’t spread fire as easily throughout your home. It will be called CMR in the description if not spelled out.

Proposed Network Designs / Re: First wired network - some concerns
« on: September 28, 2021, 10:18:43 AM »
Below are some of my thoughts after building out my own home network over time:

1) It depends on how much it costs. I personally love having my modem, router, switches, and servers all in a centralized location where it out of sight. Not only that, it makes connecting everything together easier. If you decide later to move your ISP connection to a different location (if you rearrange your living room or remodel, etc), it is more of a hassle than if it's in a centralized location where it will likely never need to be moved again. If you want a quicker, cheaper solution that you may be able to accomplish yourself, running an Ethernet cable from the ISP or private owned modem/router to your centralized location will work as long as you don't exceed 100 meters (~328 feet).

2) If your network closet is completely enclosed, you most likely need some sort of ventilation especially if you are going to have servers in the closet. If it's just a network switch, you may not need it. PoE switches run hotter but if you don't have a heavy load on it, it might not get too hot. Some people install a fan in the top and bottom of their door to draw in cold air and blow out hot air. Others blow hot air into the next room. Since I am working to finish the basement in my house, I was able to build a 4.5 ft. x 6 ft. server room. I was fortunate in that I have a return air trunk that runs parallel to the one of the walls so I only needed to run a few feet of ductwork. I installed an AC Inifinity 6" inline duct fan which has a temperature control so it runs when it gets too warm. I am able to keep the overall temperature at 73-74 degrees or below without running the fan in its maximum power (only run it at 40% since that seems to be enough without generating too much fan noise). I have 2 servers, 3 switches, 1 router, 1 modem, a NVR, and a Raspberry Pi and it stays that cool with the fan/ventilation. I also put a passthrough vent down low on the wall near the door to allow more air to be drawn in. It looks clean and it works great. Since it's in my basement, it naturally stays cooler so that helps. In the winter, it will definitely stay plenty cool since it's on the corner of the house (I have a walkout basement).

One thing you will want to avoid is to blow the hot air outside your house. I've heard of others doing it, but when I researched it, some have said it's harder on your HVAC because it creates negative pressure. Also even though it's warm air, it is still conditioned air (still may be cooler than the outside air in the summer and in the winter, you don't want to blow the warm air outside of your home). Therefore, blowing the warm air into your return air vent works well.

3) I had to redirect some of my Ethernet/coax cable from the closet under the stairwell in the basement to the server closet I built, and I used PVC pipe inside the walls. I could barely fit all of them in the size I chose, but I didn't want to use to wide of a pipe to weaken the studs. I chose the maximum size for the maximum recommended hole you can cut into studs. I only needed to run it through a couple of studs since it was close to the corner of a wall. Then I ran more PVC conduit (used gray plastic electrical conduit) above the ceiling in the server closet to my HVAC room so I can run the wires from the closet under the stairs, across the HVAC room and into the server closet. I used two 2" conduits, and I nearly filled both of them! I wish I had ran 3" conduit but I was able to do what I needed done with 2". I don't plan on adding too much more since I tried to plan ahead and ran a bunch of drops in my basement (20 drops -- 4 at 5 different locations). The 2 floors upstairs have 16 drops in comparison (that is what I had the builder to run -- I wish I had a few more ran, but I didn't want it to cost too much).

4) If you don't have the ISP connection to your house relocated, I know that a lot of people on Reddit show off their "lack racks" that are made out of Ikea furniture or custom built out of wood. With the price of lumber these days, it's probably cheaper to buy a low end server rack. For home use, cheap racks work great (or if you can find a solid used one that a business is throwing out). Being in the living room, I understand you would want it hidden. You would want to make sure it has some ventilation since routers can get pretty hot depending on what you are using.

One thing I didn't see you mention: since you are planning to run cables and use PoE switches, you may want to consider using wireless access point(s) that are powered via PoE. Since you have a small 1 floor house, you may be able to get away with one centrally located access point. If your closet will be near the center, you won't have to run a cable very far. You could just put the access point in your closet, but it could be better if it was mounted to the ceiling near the center of your house. If your house is more rectangular, you may need 1 AP on each side of the house (or if you want to extent coverage to your yard without getting outdoor APs but range may still be limited).

The main difference between associated an unassociated rules is when you make changes to the NAT port forward rule, it will be reflected in the associated rule. The unassociated rules won't get updated. You have to delete them to recreate them. I don't think there is a bug with how that works since it was intentionally designed that way for different purposes. I'm not quite sure when you would want an unassociated rule unless maybe you are worried someone will change the NAT port forward rule. However, if you did make changes and didn't realize you had an unassociated rule, it might make troubleshooting the rules more difficult.

Are your 2 private networks connected to the same OPNsense box or is one network on the ISP router and the other is on the OPNsense router? If they are on 2 separate routers, you should be able to create NAT port forward rules similar to if the WAN was connected directly to the Internet. This of course requires you uncheck blocking of private networks/bogons on the WAN interface (although I'm not sure if unchecking bogons is critical unless you are planning to use those specially reserved IP address ranges in your internal networks).

Troubleshooting / Re: Purpose of VLANs in OPNSense
« on: September 10, 2021, 09:17:15 AM »
VLANs are a way to logically divide up your network into separate smaller networks. It is useful when you want to put restrictions between devices on both networks. So you can keep your employees or guests in your house on a separate network so they can't access more critical parts of the network. VLANs can be used to improve security but by itself, it doesn't improve security. You have to have the proper firewall rules in place. VLANs + firewall rules provides you with improved security.

VLANs are not required to use but are commonly used because it saves money (it saves physical rack space, hardware costs, electricity, etc). You can accomplish the same thing without VLANs but you would need to have a separate network switch for each separate network. That is how they could separate networks before VLAN technology existed. They would use separate routers/switches to create physically separate networks.

VLANs allow you to be more efficient with your hardware. You only need 1 switch (but you can have more if you need more ports or if you want some PoE ports you can save money and buy a switch with fewer ports). You can create several networks using one router and one network switch. It will appear as though they are separate physical networks but they in fact are not on physically separate hardware. Another benefit of VLANs is you don't have to physically have every device that's on the same network plugged into the same switch. This can cause problems if you have switches in different locations in your office or home since you have to make sure the device is plugged into the proper switch. If you want to switch networks, you have to physically move the Ethernet cable. With VLANs, you can simply change which network a device belongs to by changing it on the switch itself without needing to move any cables. So you can reconfigure your network very easily with VLANs since there in increased flexibility.

If you have multiple interfaces, you could plug a small unmanaged switch (which is cheaper) in each port and have separate networks without VLANs or you could use 1 (or more) interfaces with 1 bigger network switch (depending on how many devices you want to connect) that supports VLANs and you can create 1 or more VLANs to start separating your traffic. VLANs add a little more configuration in OPNsense but it's not a lot different than setting up the physical interfaces. You just have an extra step of creating your VLAN tag(s) and then you assign the VLANs to a physical LAN interface. You will have extra configuration for your network switch. You create the same VLANs in your network switch (making sure that the port that connects to the router from your switch is set to TRUNK or allows all VLAN tags to pass through -- different switches have slightly different terminology but the concept is the same).

It sounds like your firewall is allowing all connections for all of your interfaces. If you want your traffic to be isolated, you will need to add rules to block traffic between the interfaces while still allowing traffic to the Internet (unless you want an offline network which is handy for security cameras for instance if you worry about being exposed to the Internet).

Tech Discussions / Re: Firewall rules - OPNsense Firewall Rule "Cheat Sheet"
« on: September 07, 2021, 09:56:02 AM »
The problem is that the "WAN net" alias does not mean "allow access to the Internet". The Internet essentially consists of all non-private IP addresses (except for a few other specially reserved IP ranges). Your external WAN address is only on 1 network out of billions/trillions on the Internet. That's why when you create rules you essentially need a "allow all" rule near the bottom of your rules which basically is like "allow all other" as in allow all other traffic out to the Internet (and other internal networks if you do not have any blocks in place).

So on the NA interface, you could have something like:

Block NA net to NB net
Allow NA net to any HTTP/HTTPS

Pages: [1] 2 3 4