Messages

Hello, today I upgraded 2 sites to 24.7.9_1-amd64 (I believe I was previously on 24.7.4_1-amd64). After doing that everything seemed to be OK except that I noticed that my syslog server on the LAN was no longer getting syslogs from client devices on the other side of the IPsec connection.

Upon investigation it appears the remote site's individual client device IP addresses (for each device transmitting syslog output) were all being seen on the IPsec link with the remote sites public WAN IP instead. I was seeing denies in the firewall for the public IP on the IPsec interface and then after doing a temporary rule to allow the public IP I saw the same via tcpdump on the syslog server.

I was not able to resolve the issue, and as I needed to fix it as quickly as possible I took the opportunity to convert over to WireGuard. That said, I did want to pass this information on in case it was helpful and is reproducible by someone else.

Thank you.

Ok, I will plan to do that for now. At this point I will also now continue forward with migrating to my new VoIP provider.

I hope all of the above possibly helps the OPNsense team/community, and I greatly appreciate your assistance.

Thank you.

Hello opnfwb,

Here is tonight's result for the test you proposed.

Unless it is a coincidence, it would seem that changing the setting from "conservative" to "normal" allowed my wife's call to exceed 15 minutes and not drop for the remaining duration of her conversation. The call lasted close to 28 minutes, and I observed a 60s expiration time in the OPNsense firewall sessions screen (as opposed to the 900s the conservative setting had). Once my wife ended the call, the timer then counted down and the session disappeared from the list.

I hope this information is helpful. How would you like to proceed?

Thank you.

Many thanks for your reply and suggestion. After reading what you wrote, I moved the Vonage adapter back behind OPNsense and power-cycled the Vonage adapter. As I first wanted to make sure the problem returned before trying what you mention, I left the OPNsense config as-is and had my wife make her nightly call about 20 minutes ago. Sure enough 15 minutes in, the call dropped.

Now that I have verified that the issue returned upon moving the Vonage adapter back behind OPNsense, I have just changed the config from "conservative" to "normal", and I will report back (hopefully tomorrow around same time).

Thanks again.

[success - the problem disappears]

Hello, I have used OPNsense for a few years now successfully with a Vonage VoIP plan and am not sure if the following is a regression in upgrading to the 24.7 branch or not, and I do not have an easy way to test with downgrade. I am currently running OPNsense 24.7.4_1-amd64.

I have been trying to troubleshoot an issue relating to outbound Vonage VoIP calls getting dropped (inbound does not appear to have same problem). My Vonage service is not frequently utilized except that on most evenings my wife makes a call to her mother (some lasting more than 15 minutes). The current issue is that:

- Every evening that she goes to make the call to her mother that is longer than 15 minutes, each time the call drops exactly at 15 minutes, which I believe is the 900s value that the Firewall Optimization "Conservative" setting I have always had configured uses in OPNsense. While she makes the call I observe in the Firewall sessions that this also seems to be the case and once the call drops the 900s countdown starts and eventually expires and disappears.
- She calls her mother back soon after the call drops, and the following call is able to go longer than 15 minutes without getting dropped.
- Based on the sessions table I have seen it happen with various Vonage destination server IPs (which appear to be AWS-hosted).

In my troubleshooting I have tried on multiple occasions:

- Rebooting the cable modem [Same behavior as described above]
- Rebooting the Vonage adapter [Same behavior as described above]
- Rebooting OPNsense [Same behavior as described above]
- Modifying OPNsense to have an outbound static port for the Vonage adapter (even though it has worked without this previously) [Same behavior as described above]
- Moving the Vonage adapter to connect directly to my cable modem (bypass OPNsense) [Unless a coincidence, success - the problem disappears]

While I am already in the process of migrating off of Vonage, I would still like to understand if there could be a possible UDP session timeout issue (or perhaps something else) with the more recent versions of OPNsense? I find it odd that it only happens on the initial call but the subsequent post-dropped call seems to never have the problem.

Thank you.

Just in case this helps anyone, this is currently being discussed at https://github.com/opnsense/core/issues/6514 (which may possibly end up getting tracked under additional Github issues).

Thank you for your response. I had actually tried toggling that setting, but it did not appear to make a difference. I also did a packet capture and saw the 853 traffic relating to the DNS servers defined in the Unbound section.

[NOTE:]

Hello,

I too have experienced this issue in more recent versions. Unfortunately I am unable to say when I started noticing the change, but here is some information in case it helps determine what could be going on...

1. Reboot of OPNSense at 2 locations I have running OPNsense 23.1.5_4-amd64 yields the following each time:

Notice   unbound   blocklist: https://adaway.org/hosts.txt (exclude: 0 block: 0)   
Notice   unbound   blocklist download: 0 total lines downloaded for https://adaway.org/hosts.txt   
Error   unbound   blocklist download : unable to download file from https://adaway.org/hosts.txt (error : HTTPSConnectionPool(host='adaway.org', port=443): Max retries exceeded with url: /hosts.txt (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8027cf640>: Failed to establish a new connection: [Errno 8] Name does not resolve')))

2. Manual restarting of Unbound service (e.g. restart service button on Blocklist page) does not appear to initiate download of list (based on not seeing messages such as those listed above).

3. If I disable Blocklist/Apply, then Enable Blocklist/Apply, it appears to trigger getting data:

Notice   unbound   blocklist parsing done in 0.58 seconds (7355 records)   
Notice   unbound   blocklist: https://adaway.org/hosts.txt (exclude: 2 block: 7355)   
Notice   unbound   blocklist download: 11782 total lines downloaded for https://adaway.org/hosts.txt   
Notice   unbound   blocklist download : exclude domains matching ^(?![a-zA-Z_\d]).*|.*localhost$   

NOTE: Even though the data seems to be retrieved, it appears it is not active until I then restart the service* (e.g. restart service button on Blocklist page).

*It also seems as though I need to go through the disable/enable steps then restart service an additional time to have everything fully work. I am not sure if it is always just one time, but I do know that doing the entire process once does not usually get everything working.

DNS config information that may be of interest:
1. Services->Unbound DNS->Blocklist - "AdAway List" selected and all other fields empty.
2. Services->Unbound DNS->DNS over TLS - 2 IPv4 and 2 IPv6 servers defined. All 4 using port 853.
3. Services->Unbound DNS->General - DNSSEC support enabled.
4. System->Settings->General - No DNS servers manually defined.
5. System->Settings->General - Allow DNS server list to be overridden by DHCP/PPP on WAN is enabled.

If it is not a setting issue, I am wondering if perhaps the following may relate to what I am seeing:

1. For bootup situation (DNS resolution error), perhaps a service dependency needs to be made if the blocklist process is launching before DNS resolution services are fully up and running (if that is what is actually happening).

2. For the manual service restart item, perhaps there are additional processes that need to be restarted behind the scenes as part of the service restart to trigger getting the URL to process the data.

I hope the above is helpful.

Thank you

Oh deary me. Thank you so much and I can't believe I missed that. It's been a long time since I've been on that screen and I appreciate your help.

Take care

Hello,

I am not sure if the following process created the situation I am facing, or if this is being seen by default:

- I installed 22.1.1_3 today on new hardware and imported a config file from my previous system.
- I disabled the one existing IPSec Tunnel Settings Phase 1 and Phase 2 rows I had.
- I cloned the one existing Phase 1 row I had.
- I cloned the one existing Phase 2 row I had.
- After making changes to the cloned Phase 1 and Phase 2 rows and enabling them, I clicked on checkbox to the left of the Phase 1 section "Enabled" checkbox for both the original and cloned row and noticed that the cloned Phase 2 entry was associated with the original Phase 1 entry and not the cloned one.
- At this point I could not see any "add" button to add a Phase 2 entry.
- I then deleted all Phase 1 and Phase 2 entries to and created a new Phase 1 entry.
- I am still not seeing an "add" button to create a Phase 2 entry. (image attached)

I am not sure if the steps I reference above created the problem, or if the add button in the Phase 2 entry is missing?

Any assistance would be greatly appreciated.

Thank you.