[18.7] "There were errors(s) loading the rules: no IP address found for openvpn:network" #2625
Comments
|
can you grep for me the openvpn:network rules in /tmp/rules.debug ? something similar reported in the forum. it's likely part of runtime vs. compile time pf.conf handling... |
|
|
Does this help? |
|
I too am receiving these errors hundreds in fact during boot and operation. I have 3 client VPN's in a gateway group. I also have a server VPN road warrior style. I get the following errors all the time. and this goes back to approx. 18.1.9ish. There were errors(s) loading the rules: no IP address found for ovpnc2:network eventually the interfaces will appear to be down. If I try to restart them I get an error indicating they are already running. Due to PID file corruption I believe, I must manually kill the processes and then start them. I have tried the patch above and it dose not help. Is a restart required for it to work? |
|
I need the rules grep to confirm.... |
|
root@router:~ # grep ovpnc2:network /tmp/rules.debug |
|
are you sure the errors still appear after firewall reboot? |
|
I have not rebooted. I restarted one my VPN's and 2 errors where logged. Keep in mind that errors are logged during boot and normal operation. One day I found 857 errors after about 3 days of operation.
Sent from Nine<http://www.9folders.com/>
…________________________________
From: Franco Fichtner <notifications@github.com>
Sent: Monday, August 13, 2018 2:52 PM
To: opnsense/core
Cc: agh1701; Comment
Subject: Re: [opnsense/core] [18.7] "There were errors(s) loading the rules: no IP address found for openvpn:network" (#2625)
are you sure the errors still appear after firewall reboot?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2625 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AoZJkApViC-4a7MO2VV0r4j0dd-0_wTLks5uQcrvgaJpZM4V5GBK>.
|
|
Just did a reboot. Patch does not help. |
|
I can see the patch doing the right thing in your rules so you'll have to help me out with clearing the errors and letting me know how many errors a typical boot without and with the patch has... |
|
I will get the screen shots. |
|
here is a boot with patch not the errors that can not be seen are the same as have bee reported. the 1st 2 are new. I have never seen them before. |
|
at some point maybe after 2-5 days and many errors the vpn's do go down like #2610 . I must do: |
|
@agh1701 ok, so the patch does work for the ":network" errors, and ":0" doesn't work yet. but you pasted them before. they were always there... look at your old screenshot. I'll see if I can pin down the ":0" usage and fix that as well then. :) Thanks so far! |
This simplifies the logic for the interface redirect target as we use :0 and push it directly to the kernel to resolve. From pf.conf: Tables can also be used for the redirect address of nat and rdr rules and in the routing options of filter rules, but only for round-robin pools.
|
I am having the same/similar issue as well... documented starting at this thread post: |
|
is there a patch for testing or are we waiting for the next release? |
|
It’s better to wait now. Quite a few spots have been changed to squash these errors. Although I do have to ask: does this have an operational effect or is it just a cosmetic annoyance that boot takes longer and showed these errors but system works fine? |
|
In my case I have to reload pf to get NAT to work after a boot. |
|
Operational. At some point 2 or 3 days in operation some pid file corruption occurs. the VPN's appear down(red). because the VPN's are on a group gateway the gateway goes down. in actuality they are running, I must use "ps auxw | grep openvpn" and kill them by hand. after that I am able to start them from the webui. For some reason it affects my openvpn server as it shows as down but I am able to VPN into the router. |
|
also during boot dnscrypt_proxy2 will not start. I must SSH in and start by hand. |
|
Thanks, it means we are talking about timing issues. Just to be clear, the work here will fix immediate errors, but the timing oddities and delays in the VPNs will not magically disappear and cause the system to behave normally in the process. The system will be less prone to these „deadlocks“, maybe paving the way for future research and improvements, but half of it could be related to network/VPN layout and policy routing enforcement on non-uniform endpoints.
… On 17. Aug 2018, at 21:47, agh1701 ***@***.***> wrote:
also during boot dnscrypt_proxy2 will not start. I must SSH in and start by hand.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes, I agree feels like a timing issue. I have been questioning whether the "BEFORE:" directive is being observed in the scripts in /usr/local/etc/rc.d. |
|
I have another question. what is causing the PID file corruption. after booting and making sure everything is started. 2-3 days later the services show down. I restart them and 2-3 days latter... with out rebooting. |
|
Very little is used from the stock rc.d system ever since the m0n0wall fork. That being said most of the ordering is working, in this scope basically:
Now the underlying issue is that gateway(s/ groups) are relevant for step 3 and 5 and 6, so you have OpenVPN devices not configured but asked to be part of rules that are supposed to do network-related translations that have not yet been started in case of step 3. There may be more side-effects from slow links (PPPoE can be particularly slow in this regard to fail to provide basic connectivity in step 2 and thus to be redone in step 6 so you end up with multiple rules reloads that are not fully functional and will throw these errors. There's no priority / connectivity hierarchy in gateway groups which can make this a daunting task to get just right to "program" which link is required to be able to upgrade a gateway or for it to be used at all, let alone set up and enabled in the rules dynamically. But step by step, we have time :) |
|
I've reverted back to 18.1 snapshot for now, I eliminated all the openvpn:network from my rules, but I cannot get them out of the NAT rules (They seem to be automatically added in all cases?). This results in the not having a working gateway after boot and needing a reload of pf from the serial console before hosts get IP and traffic will flow. My avoiding using the openvpn network I did get the error count down to 2 (NAT) coming from a few more. |
This simplifies the logic for the interface redirect target as we use :0 and push it directly to the kernel to resolve. From pf.conf: Tables can also be used for the redirect address of nat and rdr rules and in the routing options of filter rules, but only for round-robin pools. (cherry picked from commit 3ddea14) (cherry picked from commit 5810cc7)
|
All the patches I wrote are in 18.7.7 now. Does the issue still persist? |
|
I cleared the errors and they have not appeared in just under a day. Also since 18.7.6 my VPN's have not gone down. |
|
Thanks fichtner! |
|
@agh1701 nice, thanks for the feedback! Closing then... be sure to ping if issues seem to be back for some reason. :) |
|
@fichtner they are not all gone for me, those generatred by firewall rules are... but those cause by forwarding/NAT are not. The two disabled one are what is still triggering this for me. |
|
So 18.7.7 has the outbound fix is what I was trying to say... ;)
… On 12. Nov 2018, at 18:06, Jorge Schrauwen ***@***.***> wrote:
@fichtner they are not all gone for me, those generatred by firewall rules are... but those cause by forwarding/NAT are not.
The two disabled one are what is still triggering this for me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
With the latest 18.7.7-18.7.8... After a while of running... in this case 4 hours of uptime. I still see two issues: "There were error(s) loading the rules: no IP address found for ovpnc2" which I need to acknowledge. Additionally and in my opinion, more importantly: OPNSense is losing the status of the OpenVPN clients and servers. They show the red down icons and lose IP addresses, but they are all really still up and active. I believe OPNSense is losing track of the status of the OpenVPN connections. I believe this issue was fixed once before in a recent past release but has since resurfaced. OpenVPN errors: However, logs show: "openvpn[46774]: Cannot open TUN/TAP dev /dev/tun2: Device busy (errno=16)"... |
|
I don't think the status has ever been fixed. It's a race somewhere in the setup / teardown code in conjunction with a bumpy line. For the other thing we need: |
After boot I get "There were errors(s) loading the rules: no IP address found for openvpn:network"
I did not get this during any of the RC (or I did not notice), I do not get this if I reload the rules once the box is booted. I assume something changed order wise where OpenVPN gets started later?
Not a super big problem for me as I just need to ssh in and reload before OpenVPN works. More of an annoyance.
The text was updated successfully, but these errors were encountered: