News:

Welcome to the Home Network Guy forum!

Main Menu

Recent posts

#31
Tech Discussions / Use Static Routing to Second O...
Last post by cmonty14 - April 21, 2022, 05:08:09 AM
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
#32
How-to Discussions / Re: Questions regarding Basic ...
Last post by Home Network Guy - 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.
#33
How-to Discussions / Questions regarding Basic DMZ ...
Last post by Tanduvil - 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
#34
Troubleshooting / Re: OPNsense router strongswan...
Last post by Home Network Guy - 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.
#35
Troubleshooting / Re: OPNsense router slowing do...
Last post by JiveTalking - 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....
#36
Troubleshooting / OPNsense router strongswan-5.9...
Last post by JiveTalking - 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 :/

#37
Troubleshooting / Re: Wireguard Site-to-site wit...
Last post by Home Network Guy - 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.
#38
Troubleshooting / Re: Wireguard Site-to-site wit...
Last post by ReDaLeRt - 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:
#39
Troubleshooting / Wireguard Site-to-site with se...
Last post by ReDaLeRt - 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:

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:


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.
#40
How-to Discussions / Re: Clarification on Basic DMZ...
Last post by Home Network Guy - 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.