OPNsense Forum
Archive => 18.7 Legacy Series => Topic started by: DanMc85 on July 12, 2018, 02:02:20 am
-
I decided to give the 18.7 r1 a try...
My OpenVPN servers are working perfectly....
However, my OpenVPN Client for Private Internet Access is not.
It will not connect, no configuration has changed and was working in 18.1.11.
The OpenVPN log shows the following:
Options error: --client-connect requires --mode server
client2.conf
dev ovpnc2
verb 4
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp4-client
cipher AES-256-CBC
auth SHA256
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
client-connect "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso.php client2"
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote us-newyorkcity.privateinternetaccess.com 501
auth-user-pass /var/etc/openvpn/client2.up
ca /var/etc/openvpn/client2.ca
comp-lzo no
passtos
route-nopull
resolv-retry infinite
reneg-sec 0
disable-occ
pull-filter ignore "auth-token"
topology net30
Any suggestions on how to resolve this?
- Dan
-
I figured out a temporary fix...
Made a OPNSense Configuration Backup File.
I deleted my OpenVPN Client for Private Internet Access
I commented out these lines in /usr/local/etc/inc/plugins.inc.d/openvpn.inc after chmod 777 of the file in the shell using the file edit feature in WinSCP. Then rebooted my OPNSense box. These lines started around line 620.
// case 'p2p_tls':
// // For non user auth types setup client specific overrides, user authenticated ones are commissioned
// // using the auth script in option auth-user-pass-verify
// $conf .= "client-connect \"/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso.php {$mode_id}\"\n";
// break;
Then reloaded my backup OpenVPN configuration. It then connected.
-
Hi there,
Ah, thanks for testing and spotting this. The following should help: https://github.com/opnsense/core/commit/24f1d05c
# opnsense-patch 24f1d05c
Please confirm so we can fast-track this to RC2. :)
Thanks,
Franco
-
Hi there,
Ah, thanks for testing and spotting this. The following should help: https://github.com/opnsense/core/commit/24f1d05c
# opnsense-patch 24f1d05c
Please confirm so we can fast-track this to RC2. :)
Thanks,
Franco
I reverted my // changes and tested your patch. All seems to be working for the moment! I will let you know if anything changes!
Now I just need to figure out why suricata.log hasn't been working in a long time... always says operation is not supported by device or something like that.
- Dan
-
Clear the log file once from the log file page and it should be back then. There were incompatible changes early in 18.1.x.
Cheers,
Franco
-
Clear the log file once from the log file page and it should be back then. There were incompatible changes early in 18.1.x.
Cheers,
Franco
That worked! Thanks!
Sent from my SM-G892A using Tapatalk
-
:)
-
I figured out a temporary fix...
Made a OPNSense Configuration Backup File.
I deleted my OpenVPN Client for Private Internet Access
I commented out these lines in /usr/local/etc/inc/plugins.inc.d/openvpn.inc after chmod 777 of the file in the shell using the file edit feature in WinSCP. Then rebooted my OPNSense box. These lines started around line 620.
// case 'p2p_tls':
// // For non user auth types setup client specific overrides, user authenticated ones are commissioned
// // using the auth script in option auth-user-pass-verify
// $conf .= "client-connect \"/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso.php {$mode_id}\"\n";
// break;
Then reloaded my backup OpenVPN configuration. It then connected.
I have been Down for weeks because of this I'm so grateful that you found this. I was pulling my hair out rerolled my VPS like 200 times thinking it was missing something with applying tunnelblick's xor patch.
Hi there,
Ah, thanks for testing and spotting this. The following should help: https://github.com/opnsense/core/commit/24f1d05c
# opnsense-patch 24f1d05c
Please confirm so we can fast-track this to RC2. :)
Thanks,
Franco
Thanks for pushing this change. I implemented this, and it works just fine.
-
Yup, all sorted in 18.7. Thanks for testing!
Cheers,
Franco
-
Yup, all sorted in 18.7. Thanks for testing!
Cheers,
Franco
Could these two error messages be related to this change we made?
Whenever I reset start my OPNSense box... it hangs on loading firewall rules.
I see these alert notices in the OPNSense GUI once it loads after like 15 minutes from reboot.
There were error(s) loading the rules: no IP address fround for ovpn3:network
There were error(s) loading the rules: no IP address fround for ovpn4:network
Unless there is somewhere I should look to edit a file to resolve this? Might be a migration glitch as well.
- Dan
-
When the firewall comes up but OpenVPN is not yet active this can happen.
Can you grep for me to be sure?
# grep 'ovpn[0-9].*:network' /tmp/rules.debug
Thanks,
Franco
-
When the firewall comes up but OpenVPN is not yet active this can happen.
Can you grep for me to be sure?
# grep 'ovpn[0-9].*:network' /tmp/rules.debug
Thanks,
Franco
Is it normal for that command to give no output (unless I am typing it wrong)?
18.7.1 - issue remains.
-
Can't be both oO
Let's widen the grep then...
# grep :network /tmp/rules.debug
Cheers,
Franco
-
Can't be both oO
Let's widen the grep then...
# grep :network /tmp/rules.debug
Cheers,
Franco
I found the grep command issue... anyways here is the output if it helps resolve this issue or maybe I have rules that I do not need.
nat on ovpns3 inet proto {tcp udp} from ovpns3:network to {PRIVATE IP ADDRESS OMITTED} port {53} -> ovpns3 port 1024:65535 # Redirect All Unknown DNS Servers to Internal DNS
nat on ovpns3 inet proto {tcp udp} from ovpns3:network to {127.0.0.1} port {123} -> ovpns3 port 1024:65535 # Redirect All Time Inquires to This Firewall
pass in quick on hn0 inet from {PRIVATE IP ADDRESS OMITTED} to {(ovpns3:network)} keep state label "USER_RULE: Allow Clients Access to Domain Controller on Remo..." # e459891a011793b7e3cb4f5070b1082b
pass in quick on hn0 inet from {(ovpns3:network)} to {(hn0:network)} keep state label "USER_RULE" # aa280ba13da6a0070fc7dff60ae496da
nat on ovpns4 inet proto {tcp udp} from ovpns4:network to {PRIVATE IP ADDRESS OMITTED} port {53} -> ovpns4 port 1024:65535 # Redirect All Unknown DNS Servers to Internal DNS
nat on ovpns4 inet proto {tcp udp} from ovpns4:network to {127.0.0.1} port {123} -> ovpns4 port 1024:65535 # Redirect All Time Inquires to This Firewall
pass in quick on hn0 inet from {PRIVATE IP ADDRESS OMITTED} to {(ovpns4:network)} keep state label "USER_RULE: Allow Clients Access to Domain Controller on Site..." # 9dbe6a70da2a9a5461f6f3e4e532ccde
pass in quick on hn0 inet from {(ovpns4:network)} to {(hn0:network)} keep state label "USER_RULE" # ffa36a87892035d410807c749bd6a3b9
pass out log route-to ( ovpnc2 PRIVATE IP ADDRESS OMITTED ) from {ovpnc2} to {!(ovpnc2:network)} keep state allow-opts label "let out anything from firewall host itself"
pass in log quick on hn1 route-to ( ovpnc2 PRIVATE IP ADDRESS OMITTED ) inet from {(hn1:network)} to {any} keep state label "USER_RULE" # 0618b11751c2e8b2eb0f3d4807c00856
pass in quick on ovpnc2 route-to ( ovpnc2 PRIVATE IP ADDRESS OMITTED ) inet from {(ovpnc2:network)} to {any} keep state label "USER_RULE" # ce37ac04bdf4e549df26c96894cc3b60
-
Ok, we're working on this issue here. There is a patch for your issue that should work already:
https://github.com/opnsense/core/issues/2625
Cheers,
Franco
-
Ok, we're working on this issue here. There is a patch for your issue that should work already:
https://github.com/opnsense/core/issues/2625
Cheers,
Franco
I ran patch 71043f1
I still see "Configuring Firewall... failed" during the boot sequence. However, it passes right by, instead of hanging there for 5-10 minutes as it was doing before.
Also it may be unrelated but it also stays at "Configuring Dynamic DNS" for a few minutes, as well.
I still have 5 Notices in the GUI. Two of them are new after running the patch. (I acknowledged notices before redoing a reboot)
New:
There were error(s) loading the rules: /tmp/rules.debug:84: no translation address with matching address family found. - The line in question reads [84]: nat on ovpns3 inet proto {tcp udp} from (ovpns3:network) to {PRIVATE IP} port {53} -> ovpns3 port 1024:65535 #
The other notices are the same no IP address found for ovpns3, ovpns4, and ovpnc2:0
-
The hangs and error messages point to traffic being pushed over OpenVPN links that are not yet set up / active.
The line in question reads [84]: nat on ovpns3 inet proto {tcp udp} from (ovpns3:network) to {PRIVATE IP} port {53} -> ovpns3 port 1024:65535 #
Points to "ovpns3" causing the error, again, because it's being configured without being up/configured itself. I've added more () magic here in subsequent commits but testing is difficult and we need to give it some time on -devel.
Cheers,
Franco
-
The hangs and error messages point to traffic being pushed over OpenVPN links that are not yet set up / active.
The line in question reads [84]: nat on ovpns3 inet proto {tcp udp} from (ovpns3:network) to {PRIVATE IP} port {53} -> ovpns3 port 1024:65535 #
Points to "ovpns3" causing the error, again, because it's being configured without being up/configured itself. I've added more () magic here in subsequent commits but testing is difficult and we need to give it some time on -devel.
Cheers,
Franco
If I switch from Production to Development build. Are those changes part of the update download or would another patch be needed to test?
Sent from my SM-N950U using Tapatalk
-
Most went in after the latest devel version was built. You should stay on production for now.
Cheers,
Franco