1
General Discussion / Re: restarting unbound by cron
« on: January 30, 2019, 09:23:45 pm »
Ok, we will investigate this, thank you!
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.
Pages: [1]
2
General Discussion / Re: restarting unbound by cron
« on: 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!
OPNsense 18.7.10_3-amd64
FreeBSD 11.1-RELEASE-p18
OpenSSL 1.0.2q 20 Nov 2018
Many thanks!
3
18.7 Legacy Series / Re: How to reload unbound using a script?
« on: January 24, 2019, 10:57:48 pm »4
General Discussion / Re: restarting unbound by cron
« on: January 24, 2019, 10:18:06 pm »
Screenshot
5
General Discussion / Re: restarting unbound by cron
« on: 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:
Information in file:
Restart configd service:
Verify new action file works as expected:
Next I went to Services:Unbound DNS:Log File and the logs show Unbound restarted successfully.
Then I did this to ensure it would show up in the OPNsense GIU:
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!
Here are the steps I followed, please help me understand where I failed.
Use vi to create file:
Code: [Select]
root@opnsense:~ # vi /usr/local/opnsense/service/conf/actions.d/actions_unbound_restart.confInformation in file:
Code: [Select]
[restart]
command:/usr/local/sbin/pluginctl dns
parameters:
type:script
message:Restart Unbound DNS Service
description:Restart Unbound DNS ServiceRestart configd service:
Code: [Select]
root@opnsense:~ # service configd restart
Stopping configd...done
Starting configd.Verify new action file works as expected:
Code: [Select]
root@opnsense:~ # configctl unbound_restart restart
OKNext I went to Services:Unbound DNS:Log File and the logs show Unbound restarted successfully.
Code: [Select]
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:
Code: [Select]
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
« on: 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.
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
« on: 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
« on: October 17, 2018, 12:53:28 am »
Bump. Same problem. Thanks!
9
General Discussion / Re: TCP:FA and TCP:RA and TCP:FPA
« on: March 01, 2017, 05:15:46 pm »
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!
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
« on: 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!
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
General Discussion / [SOLVED] TCP:FA and TCP:RA and TCP:FPA
« on: February 23, 2017, 09:51:03 pm »
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
--------------------------------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------------------------------
Pages: [1]