Menu

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.

Show posts Menu

Messages - mtn406

#1
General Discussion / Re: restarting unbound by cron
January 30, 2019, 09:23:45 PM
Ok, we will investigate this, thank you!
#2
General Discussion / Re: restarting unbound by cron
January 26, 2019, 06:25:42 PM
My apologies, we have no idea why unbound keeps dying. If you can direct me where to look or which log files to post I will. Attached is a screenshot of our unbound config page. I do not think we are running LibreSSL as it is not selected in the firmware page, screenshot also attached.

OPNsense 18.7.10_3-amd64
FreeBSD 11.1-RELEASE-p18
OpenSSL 1.0.2q 20 Nov 2018

Many thanks!
#4
General Discussion / Re: restarting unbound by cron
January 24, 2019, 10:18:06 PM
Screenshot
#5
General Discussion / Re: restarting unbound by cron
January 24, 2019, 10:17:13 PM
Working from this thread and the following posts: https://forum.opnsense.org/index.php?topic=2263.0 and http://kb.unixservertech.com/other/networking/opnsense/cron-jobs I was able to create the following and get everything to work from the command line, and schedule via the Cron GUI, but it is still failing to run via the Cron GUI  ???

Here are the steps I followed, please help me understand where I failed.

Use vi to create file:
root@opnsense:~ # vi /usr/local/opnsense/service/conf/actions.d/actions_unbound_restart.conf

Information in file:
[restart]
command:/usr/local/sbin/pluginctl dns
parameters:
type:script
message:Restart Unbound DNS Service
description:Restart Unbound DNS Service


Restart configd service:
root@opnsense:~ # service configd restart
Stopping configd...done
Starting configd.


Verify new action file works as expected:
root@opnsense:~ # configctl unbound_restart restart
OK


Next I went to Services:Unbound DNS:Log File and the logs show Unbound restarted successfully.
Date                Message
Jan 24 16:01:29     unbound: [67123:0] info: start of service (unbound 1.8.3).


Then I did this to ensure it would show up in the OPNsense GIU:
root@opnsense:~ # /usr/local/etc/rc.restart_webgui
Starting web GUI...done.
Generating RRD graphs...done.


I then went to System:Settings:Cron and created a cron job (image attached):

But when the time comes for it to run and I then check Services:Unbound DNS:Log File I do not see that it has restarted.

Please help.

Thanks!
#6
General Discussion / Re: restarting unbound by cron
January 24, 2019, 04:20:47 PM
Confirmed, this is still an issue on:

OPNsense 18.7.10_3-amd64
FreeBSD 11.1-RELEASE-p18
OpenSSL 1.0.2q 20 Nov 2018

We are having to manually restart unbound on average at least once a day.
#7
General Discussion / Re: restarting unbound by cron
November 12, 2018, 10:23:43 PM
Bump, please. This is becoming a significant issue for us and requires manual restart of unbound at least daily.
#8
General Discussion / Re: restarting unbound by cron
October 17, 2018, 12:53:28 AM
Bump. Same problem. Thanks!
#9
Franco,

Thank you for the reply. We did set to "conservative" and rebooted both the OPNsense firewall and clients but it did not help which makes me think it was an issue in the cloud at the hosting site. (And the fact that the next day suddenly everything worked.)

Thank you!
#10
General Discussion / Re: TCP:FA and TCP:RA and TCP:FPA
February 24, 2017, 09:32:40 PM
Update:

Today, the software team is running 3 different versions of the custom application with no issue. We made no network changes. Therefore, perhaps this issue came about because of something on the server we were connecting to on the Internet.

IF anyone has any thoughts on this, please share.

Thank you!
#11
Hello! Please excuse me if this is an ignorant question. I did look through these forums and Google.

The issue is users complaining about slow performance of a custom application (and blaming the network). The network is proven fast with "regular" applications (browsing, downloads, etc) and that lead me to dive into the log files (section copied below). Unfortunately, I am at a loss to understanding what these log files mean and would appreciate some assistance and solution.

It appears the issue is in TCP:FA and TCP:RA and TCP:FPA.

First question is: What do these mean, please?

In Googling I found some pages talking about pfSense and was able to follow the suggestions, but it has NOT solved
the problem.

https://knowledge.zomers.eu/pfsense/Pages/How-to-solve-connectivity-issues-with-dropped-RA-and-PA-packets.aspx

In OPNsense I found the settings in Firewall --> Settings --> Advanced and did set things to "conservative   Tries to avoid dropping any legitimate idle connections at the expense of increased memory usage and CPU utilization." Again, it does not appear to have worked as the TCP:FA/RA/FPA messages are still showing up.

Next, this page (https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting) mentions:

Asymmetric Routing
If reply traffic such as TCP:A, TCP:SA, or TCP:RA is shown as blocked in the logs, the problem could be asymmetric routing. See Asymmetric Routing and Firewall Rules for more info.

I do not understand how this can be "Asymmetric Routing" as the OPNsense box only has 1 WAN and 1 LAN and 0 VLAN.

I understand this might be an issue with the custom application. What can I go back to the application team with to help them (and defend the network team), please?

--------------------------------------------------------------------------------------------------------
https://www.supermicro.com/products/system/1u/5018/sys-5018d-fn4t.cfm
8 core Xeon with 64 GB RAM and M.2 SSD
running:
OPNsense 17.1.2-amd64
FreeBSD 11.0-RELEASE-p7
OpenSSL 1.0.2k 26 Jan 2017
--------------------------------------------------------------------------------------------------------
Act   Time   If   Source   Destination   Proto
Feb 23 20:16:27   LAN     192.168.13.112:54441     23.194.108.175:443
a23-194-108-175.deploy.static.akamaitechnologies.com   TCP:RA
Feb 23 20:16:27   LAN     192.168.13.112:54442     23.194.108.175:443
a23-194-108-175.deploy.static.akamaitechnologies.com   TCP:RA
Feb 23 20:12:28   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:RA
Feb 23 20:12:18   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:14   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:10   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:09   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:PA
--------------------------------------------------------------------------------------------------------