Welcome to the Home Network Guy forum!

Recent Posts

Pages: [1] 2 3 ... 10
1
And now I'll open the more specific questions.

But I'll try to describe my home network first...

In my network there is

This ISP router has only some features that could be helpful, e.g. static routing table, open ports to WAN of specific clients connected to LAN.

Any router has multiple ethernet ports.
I'm planning to install OpenWRT on Mikrotik hEX S and OPNsense on gateprotect GPO 150.
Generally I was thinking about a setup like this:
Internet > ISP router (= modem & router)
ISP router > OpenWRT router
OpenWRT router > DMZ Switch
OpenWRT router > OPNsense router
OPNsense router > LAN Switch

This means the DMZ is in between external and internal firewall. To my understanding this is a recommended setup to strengthen security.

What makes setup a little more complicated: my ISP offers 2 WAN:
  • static public IP
  • and dynamic public IP

Luckily this ISP router provides bridge-mode for static public IP.
So consequently the OpenWRT router will have 2 WAN ports.

Now here are the questions:
Is it advisable to setup "NAT disabled for homelab" if ISP router only offers static routing, but very limited firewall rules (specific ports can be opened for internal devices connected to this ISP router)?
Is it advisable to use the same subnet for managing any network device's WebUI? Or would this undermine all measures for strengthen security?

The ISP router can only provide 1 subnet (= LAN) that is used for administration.
And WANdynamic of OpenWRT router will be connected to this subnet.
I'm not sure if it makes sense to use this LAN for administration of all network devices then.
Certainly I could use ISP router LAN for administration of this router only and another network for administration of OpenWRT and OPNsense router.

THX
2
Hello,

based on the turorial Use Static Routing to Second OPNsense Router with NAT Disabled for a Homelab I would like to discuss some generic questions and some questions specific for my home network.

I'll start with the generic question:
I could connect the secondary router to a separate, unused interface on the primary router.
What do you mean when saying "unused interface"?

THX
3
How-to Discussions / Re: Questions regarding Basic DMZ How-to
« Last post by Home Network Guy 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 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.
4
How-to Discussions / Questions regarding Basic DMZ How-to
« Last post by Tanduvil on April 03, 2022, 02:57:28 PM »
Hello,

I have two quiestions regarding this article: https://homenetworkguy.com/how-to/create-basic-dmz-network-opnsense

First of all: what a great article, thanks so much for all your time and effort!

Regarding the second DNS-Block-Rule for Rogue users, if the destination of the "Allow DNS" Rule would be "This Firewall" instead of DMZ Address - would the DNS block rule then be obsolete?

Second question: For blocking the private networks, would it be possible to switch it, means creating a block rule for the private networks without the destination/invert? Or would it have a different impact?

Again, thanks so much!
Greetings from Germany :)

Chris
5
Troubleshooting / Re: OPNsense router strongswan-5.9.4 error (Update)
« Last post by Home Network Guy 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.
6
Troubleshooting / Re: OPNsense router slowing down & strongswan-5.9.4 error
« Last post by JiveTalking on February 06, 2022, 01:16:26 PM »
Well, I think I've solved my slow down issue :D it was my VPN which needed some tweaking.

But I still cannot find (internet searching) any tips on how to deal with a error as I have posted here.

- I mean do I remove strongswan-5.9.4, or would this cause other issues?

Can anyone point me to where how to deal with errors is laid out?

I really only trust this forum  :-* but I did search OPNsence forum but didn't find anything....
7
Troubleshooting / OPNsense router strongswan-5.9.4 error (Update)
« Last post by JiveTalking on February 02, 2022, 01:12:03 PM »
Hello,

UPdate: I found out that there is a new strongswan release strongswan-5.9.5-released, but it does not show up for updating in my OPN and I do not know why.  Maybe I need to uninstall it.
Here is the information should anyone else be needing it https://www.strongswan.org/blog/2022/01/24/strongswan-vulnerability-(cve-2021-45079).html



I find this:
***GOT REQUEST TO AUDIT SECURITY***
Currently running OPNsense 21.7.8 (amd64/LibreSSL) at Tue Feb  1 10:01:11 PST 2022
Fetching vuln.xml.bz2: .......... done
strongswan-5.9.4 is vulnerable:
  strongswan - Incorrect Handling of Early EAP-Success Messages

1 problem(s) in 1 installed package(s) found.
***DONE***

So I reinstalled Strongswan, ran the test again, and the error remains - I have no idea what to do now, this will be a recurring theme as this posts goes along.

I also received this:
The default strongSwan configuration interface have been updated to vici.
To use the stroke interface by default either compile the port without the vici option or
set 'strongswan_interface="stroke"' in your rc.conf file.
Checking integrity... done (0 conflicting)

This means nothing to me, and again I have no idea what to do.



Any help is greatly appreciated :/

8
Troubleshooting / Re: Wireguard Site-to-site with selective routing
« Last post by Home Network Guy 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.
9
Troubleshooting / Re: Wireguard Site-to-site with selective routing
« Last post by ReDaLeRt on December 28, 2021, 10:03:30 AM »
Additionally, I manage to capture a traceroute from a client on the B site, to the IP range 213.13.24.0/24:
10
Troubleshooting / Wireguard Site-to-site with selective routing
« Last post by ReDaLeRt on December 28, 2021, 08:19:16 AM »
Hello.

I followed the tutorial here, as a first troubleshooting step: https://homenetworkguy.com/how-to/configure-wireguard-opnsense/#_

My issue with selective routing is accessing a specific public ip range (213.13.24.0/24) from an Openwrt Site "B" connected site-to-site through an OPNsense Site "A".

Configuring that subnet range on the Site "B" as "allowed ips" to the tunnel, so that Site "B" could access it through the Site "A", it isn't working as expected:

Code: [Select]
tracert 213.13.24.11

Tracing route to 213.13.24.11 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  OpenWRT.lan [192.168.0.1]
  2    17 ms    14 ms    15 ms  10.0.0.1
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.

The site "B" LAN range is 192.168.0.0/24 with tunnel IP 10.0.0.2/32, the Site "A" is 192.168.10.0/24 with tunnel IP 10.0.0.1/32, and the WG tunnel range is 10.0.0.0/24. Both sites are connected to the internet with public IP addresses on their WAN interfaces.

The OPNsense configuration is presented within the attachments bellow.

A half workaround on the site B is to enable masquerading to get selective routing, but blocks site A to access site B:

Code: [Select]
uci set firewall.lan.masq="1"
uci commit firewall
/etc/init.d/firewall restart

I'm hoping that someone could shed some light into this. :-)

Thanks.
Pages: [1] 2 3 ... 10