Messages

I set up the proxy server and discovered that it won't do transparent proxy even though I selected that option. It does filter and behave properly if I treat it as a manual proxy. Any ideas on that?  I updated to 16.1.17 but still no go.

I had to pull the Opnsense firewall because it kept crashing every couple of days. When it crashed, I couldn't connect to the web interface or ping the lan card. When I checked the connected monitor, the screen was just full of jibberish. I didn't have time to troubleshoot at that point because I was going to be out of the office for 4 days. When I got back I started checking things out. Checked the logs but couldn't find anything, may have lost the pertinent log info because of the delay in looking at it. Did full diagnostics on the hardware but found nothing wrong. Ran it for several days off a live Linux Mint cd without any failure. I decided to set it up on a secondary network I have but it hasn't run long enough to reproduce the failure, apparently. Wondering if anyone else has experienced this or how to find out what is happening. I also updated to the latest version today, 16.1.17 - I think, so maybe this issue won't return.??

That was really fast. Thanks!

It is but if you clone an existing rule then you have to go looking for it and that is where I missed it. It has been awhile since I created a rule from scratch and I forgot that the any option existed. My fault I suppose. Just thought that having that option always at the top of the list might be helpful.

I looked at the settings for the rules a bit more and found that there is an any option for filtering protocols. I didn't notice it at first because it is way down the list. I actually thought there should be an any option but missed it. It might make sense to have the any at the top of the list instead of buried down where it is. Just a thought.

Feeling a bit dense about now. I had forgotten that icmp is another protocol. Kind of just considered it to be something that used UDP. Not sure where that came from. It seems I am forgetting things I learned a very long time ago, kind of scary.  I now see that I can setup a rule to block icmp but it isn't really necessary in this case.  I have now tested using a web browser since the ip addresses were tied to websites and I figure by blocking both TCP and UDP, which I have now done, I should be covered for any unwanted traffic.  Thanks for your help.

That makes sense. It appears that even choosing upd/tcp makes no difference.

At this point I have upgraded to the latest version and did a reboot afterward. I have tested by pinging the ip address. Since the ping still works I assume the rule isn't working. Not sure how to reload the filter rules.

The anti-lockout rule for the lan is first. Should that be moved?

I need to add that I am using the latest version, 16.1.13

I am having trouble getting the firewall rules to actually work. Trying to block outgoing traffic to a particular ip address but it doesn't seem to work. Attached is a screen shot of the rule I am trying to use. The gateway setting is default. Not sure what is wrong.

Started out setting up OpenVPN with 15.7 but I couldn't get the service to start also couldn't get the client to download. Kept getting errors I couldn't resolve. Upgraded to 16.1.8 and recreated everything. That got the service working and I was able to create a client package for windows but no matter which client version I tried, none of them would extract. Extracting just stayed at zero. I was able to get the archive and client configuration files to download and open.  I know I can manually install the client software but need to know where to put which files to get it to work right, if all of the needed files are there. That would allow me to test and see if it will meet the need.

There is another interesting way to block such traffic. If your network uses an internal DNS server that gets handed out by DHCP then you can add an entry to the DNS server that points facebook.com, or other, to 127.0.0.1. The page will not load and they get a standard, failed to connect, error or a failed security certificate error. This works regardless of whether you are setup to examine SSH traffic or not. The page has to be resolved by DNS first and this causes it to resolve to a non-working address.