Messages

1

General Discussion / Re: OPNSense - Pi-Hole

« on: September 02, 2023, 11:43:49 pm »

Patuff,

Would you happen to have a link available that explains how you configured opnsense to only use pi-hole for DNS?  (Or could you reply with how you configured opnsense to only use pi-hole for DNS?)  Any help would be greatly appreciated.

2

General Discussion / [SOLVED] Re: Firewall>NAT>Port Forward issue with port > 32807 - Possible bug?

« on: June 07, 2021, 11:12:43 pm »

Greetings again Forum:

I discovered the problem.  Attached is a slightly larger screen shot (opnsense-nat2.png) that provides the 'to:' port range under my 'Destination port range' configuration.  My 'from:' entry is 61713, but my 'to:' entry is HTTP.  This combination will throw the error "The target port range must be an integer between 1 and 65535" when in fact the target port range is indeed an integer between 1 and 65535.  This appears to be a bug.  Would somebody else please verify this behavior on their firewall?

Background:  I am coming from years of pfsense experience, where the web user interface has a slightly different approach with port forwarding.  In pfsense, the fields 'from:' and 'to:' default to 'other' with no numerical entry in a new NAT Port Forward entry.  (re: pfsense-nat-new.png)  Further, if no port range is required, the 'to:' entry can simply be left blank.  I have grown so accustom to creating port forwards with this workflow that the "must be an integer between 1 and 65535" error was throwing me off when the actual problem appears to be that the 'to:' and 'from:' port entries must match to forward a single port.  I played a guessing game with the port numbers to determine what integer it would finally accept, which provided no logical clue...

In OPNsense, the fields 'from:' and 'to:' default to 'HTTP' with no numerical entry in a new NAT Port Forward entry.  (re: opnsense-nat-new.png)  As a result, the HTTP must be changed to 'other' and then the port must be entered a second time into the 'to:' field.  If the 'to:' field is simply left at default, the user is incorrectly told that the port range is an incorrect integer from 1-65535, when in fact it likely is a valid port number.  The solution is to make the 'to;' field = the 'from:' field.

3

General Discussion / [SOLVED] Re: Firewall>NAT>Port Forward issue with port > 32807 - Possible bug?

« on: June 06, 2021, 07:10:22 pm »

Greetings Forum:

I am running into an issue when trying to enter a Port Forward rule with a port number larger than 32807.  If I enter a port of 32808 or greater, OPNSense complains "The target port range must be an integer between 1 and 65535."  If I lower it back to 32807, the rule is accepted.  I must be missing something very obvious here... ??

4

General Discussion / Re: IP Camera Rule

« on: June 06, 2021, 06:58:18 pm »

Greelan:

Thank you for the word of caution and advice.  I already use OpenVPN on my pfsense box, but primarily for LAN access to my home network while away from home. 

To block outgoing traffic initiated by the cameras, create a block rule on the interface that the cameras are connected to (eg LAN), with the camera IP alias as the source and the destination as any.

I will give this a try.  For some reason I thought this approach would also block responses from the cameras initiated from the WAN side.  I am also experimenting with creating a block rule to keep the devices within my ipcamzone alias isolated from the rest of the LAN.  I'll report back how it goes.  Thank you for the quick reply!

5

General Discussion / IP Camera Rule

« on: June 05, 2021, 03:37:33 am »

Greetings Forum:

I am a new user with OPNsense.  I am looking for suggestions / help with creating a rule that would allow outside WAN requests in to an 'ipcamzone' alias I have setup.  The goal is to block any outgoing requests initiated from cameras in the ipcamzone alias (they shouldn't be talking out on their own), yet allow outside WAN requests in for connections when the camera is connected to for normal use.  Any suggestions?