Hello,
We have acquired the Static IPSec VPN for Business and configured 3 tunnels, 2 are Azure and 1 to another location. Although the tunnels seem to be stable, the location one seems to crash from time to time, no errors that I can see, but the worst thing is that several times a day I cannot access the Static IPsec VPN for business menu item, as I am getting the following error:
Ooooops: exception 'clearos\apps\base\Engine_Exception' with message '000 using kernel interface: netkey' in /usr/clearos/apps/base/libraries/Shell.php:227 Stack trace: #0 /usr/clearos/apps/static_vpn/libraries/Openswan.php(582): clearos\apps\base\Shell->execute('/usr/sbin/ipsec', 'auto --status', true, Array) #1 /usr/clearos/apps/static_vpn/controllers/report.php(73): clearos\apps\static_vpn\Openswan->get_tunnel_status() #2 /usr/clearos/framework/application/libraries/Page.php(641): Report->index() #3 /usr/clearos/framework/application/libraries/Page.php(504): Page->view_controllers(Array, 'Static IPsec VP...') #4 /usr/clearos/apps/static_vpn/controllers/static_vpn.php(76): Page->view_forms(Array, 'Static IPsec VP...') #5 [internal function]: Static_Vpn->index() #6 /usr/clearos/framework/system/core/CodeIgniter.php(535): call_user_func_array(Array, Array) #7 /usr/clearos/framework/htdocs/app/index.php(224): require_once('/usr/clearos/fr...') #8 {main}
If I do stop/start of the service, it start working again, but as you can understand I can't stop all tunnels several times a day.
Can anyone help?
ClearOS version is the community one, 7 with all latest updates.
We have acquired the Static IPSec VPN for Business and configured 3 tunnels, 2 are Azure and 1 to another location. Although the tunnels seem to be stable, the location one seems to crash from time to time, no errors that I can see, but the worst thing is that several times a day I cannot access the Static IPsec VPN for business menu item, as I am getting the following error:
Ooooops: exception 'clearos\apps\base\Engine_Exception' with message '000 using kernel interface: netkey' in /usr/clearos/apps/base/libraries/Shell.php:227 Stack trace: #0 /usr/clearos/apps/static_vpn/libraries/Openswan.php(582): clearos\apps\base\Shell->execute('/usr/sbin/ipsec', 'auto --status', true, Array) #1 /usr/clearos/apps/static_vpn/controllers/report.php(73): clearos\apps\static_vpn\Openswan->get_tunnel_status() #2 /usr/clearos/framework/application/libraries/Page.php(641): Report->index() #3 /usr/clearos/framework/application/libraries/Page.php(504): Page->view_controllers(Array, 'Static IPsec VP...') #4 /usr/clearos/apps/static_vpn/controllers/static_vpn.php(76): Page->view_forms(Array, 'Static IPsec VP...') #5 [internal function]: Static_Vpn->index() #6 /usr/clearos/framework/system/core/CodeIgniter.php(535): call_user_func_array(Array, Array) #7 /usr/clearos/framework/htdocs/app/index.php(224): require_once('/usr/clearos/fr...') #8 {main}
If I do stop/start of the service, it start working again, but as you can understand I can't stop all tunnels several times a day.
Can anyone help?
ClearOS version is the community one, 7 with all latest updates.
Share this post:
Responses (4)
-
Accepted Answer
Unfortunately the app is a bit sensitive to changes and can write invalid configuration files. Configuration files are in /etc/ipsec.d.
From the errors I've seen so far, in each .conf file:
- Only the first line should start "conn" in the first column. Delete all other lines starting "conn"
- Remove all blank lines
- All lines except the first must be indented
In each secrets file:
- The first character must no be blank
Try fixing any of these you find then restart ipsec.
If that does not work, can you either post your .conf files and I'll see if I can correct them or delete them then try re-entering them. - Only the first line should start "conn" in the first column. Delete all other lines starting "conn"
-
Accepted Answer
Hello Nick,
I check all config files and secrets files, and everything is ok, none of the issues you stated are present. I'll get the conf files and post post them without the IP's (confidentiality and all), as for deleting and reentering, I have tried that (before posting I have read a couple of your answers on similar posts). -
Accepted Answer
Below all tunnel conf files.
conn tun1
type=tunnel
authby=secret
auto=add
left=external left IP
leftnexthop=external left IP gateway
leftsourceip=internal left IP gateway
leftsubnet=internal left subnet /24
right=external right IP
rightsubnet=internal right subnet /24
salifetime=1h
ikev2=permit
pfs=no
rekey=yes
ike=aes256-md5;modp1024
phase2alg=aes256-md5;modp1024
conn tun2
type=tunnel
authby=secret
auto=add
left=external left IP
leftnexthop=external left IP gateway
leftsourceip=internal left IP gateway
leftsubnet=internal left subnet /24
right=external right IP
rightsubnet=internal right subnet /24
salifetime=1h
ikev2=permit
ike=aes128-md5;modp1024
phase2alg=aes128-md5;modp1024
pfs=no
rekey=yes
conn tun3
type=tunnel
authby=secret
auto=add
left=external left IP
leftnexthop=external left IP gateway
leftsourceip=internal left IP gateway
leftsubnet=internal left subnet /24
right=external right IP
rightsubnet=internal right subnet /24
salifetime=1h
ikev2=permit
pfs=no
rekey=yes
ike=aes128-md5;modp1024
phase2alg=aes128-md5;modp1024 -
Accepted Answer
In terms of the webconfig, I think your conns are OK, so it just must be IPsec failing on its own rather than caused by the webconfig generating invalid configs. I do, however, have some comments on your conns:
1 - for the moment never specify an modp section in phase2alg. If you don't, it will follow phase 1 which is fine. If you do there are some bugs around and this could be causing IPsec to fail.
2 - If you don't specify ike and phase2alg, you get aes256-sha1;modp1536 (I think the modp1536 is the value you get), so the default is stronger than you have specified. I'd go with the defaults or stronger.
3 - It is now recommended not to use md5 as it is too weak, so I suggest you change to sha1. sha256 is better but not yet supported by the webconfig.
4 - modp1024 is also no longer recommended on security grounds. It is only there for legacy reasons.
5 - If you control both ends, set pfs to yes at one end at least. The other end will follow and ignore the setting pfs=no. If you want, read what "man ipsec.conf" has to say about it.
6 - Unless you are controlling the tunnels manually, normally you'd have auto=start (Connection Mode = Automatic) rather than auto=add (Connection Mode = Listen). If your connection is listening you would normally have rekey=no, but it starts getting a bit more complicated. If you are not gong to rekey you must have your phase1 and phase2 key lives as long or linger than the end which is initiating the connection.
7 - I am not sure of the advantage of permitting IKEv2. Do you know if a v1 or v2 connection is being negotiated? I would suspect v1 as you have to force v2 at one end to get v2.
8 - nexthops are generally a waste of effort. Libreswan works them out for itself.
Can you at least adjust your phase2alg then post your logs if a conn goes down again? Also can you confirm that add end points have static IP's? If any are dynamic you need a different approach.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »