Menu
▾
▴
#657 VPN broken
Since release 1.4.14 something in the VPN area is definitely broken. This applies to 1.4.14, 1.4.15 and 1.4.16.
After upgrading from 1.4.13, existing VPN tunnels are functional for a while, as long as the configuration dialog never was opened.
New VPN tunnels will not work at all.
Importing a saved 1.4.13 config into a fresh 1.4.14 installation leads to broken VPN tunnels.
Ticking "Active" in the general VPN section should start the VPN service (see system state). This does not apply for 1.4.15 and 1.4.16 (1.4.14 not tested).
Thus a fresh installation will never have a running VPN service.
Please fix that !
Logged In: YES
user_id=1041094
Originator: NO
Ah,
this is not the place for debugging complicated things.
Try a support forum or provide a detailled report
exposing the bug (and the workaround if any).
1.4.14 effectively changed some rules for simplifying
OPENVPN installation. Only you can provide info on
conflicts or other problems.
Thank you.
Franck
Logged In: YES
user_id=691649
Originator: NO
As Franck write, we need more details to be able to investigate why your configuration was broken.
Is it a net to net or a road warrior configuration?
What is used for authentification?
Which error appear in the log?
Logged In: YES
user_id=1082453
Originator: YES
to be more precise:
Scenario 1
1. IPCop V1.4.13 installed and configured (no VPN for now)
2. in VPNs tab, klick activate (general settings)
3. VPN service in SYSTEM-STATE of STATUS tab is running (as expected)
4. in VPNs tab, check some of the PLUTO DEBUG options
5. in SYSTEM-LOGS of LOGS tab, select IPSec and than refresh to see IPSec logs
Now repeat steps 1. to 5. on a fresh installation of IPCop V1.4.15 or V1.4.16
and you will see no running VPN service and no IPSec logs.
Scenario 2
1. IPCop V1.4.13 installed and configured including various VPN tunnels
most of mine are fixed to fixed IP, LAN to LAN tunnels to ZyXEL devices
(with Preshared Key, 3DES, MD5, DH2 and no PFS)
2. upgrade IPCop V1.4.13 to V1.4.15 or V1.4.16 (don't touch VPN configs up to now)
3. try to activate/deactivate existing VPN tunnels (working as expected)
4. now enter the VPN configuration dialogs (normal and advanced) of an existing tunnel,
change things, save, change back to previous settings and save again.
5. try to activate/deactivate the tunnel you touched in step 4.
(now the tunnel stays dead !)
The GUI for the VPN configuration (normal and/or advanced) seems to kill a working config.
By the way; PLUTO-DEBUG (IPSec) logging cannot be activated after upgrading from V1.4.13
to V1.4.15 or V1.4.16 when PLUTO-DEBUG was not activated before upgrading.
Logged In: YES
user_id=1041094
Originator: NO
Ok, I see the sequence producing the problem.
When no vpn is enabled (be defined) the start
sequence do nothing, because there is nothing to do.
(the start sequence is when you enble vpn globally).
After that you switch on one of your not enabled vpn
(or the first one created) and nothing happens because
ipsecctrl re-start the connection only. The problem is
I did not call the loadmodules here.
Just disable/save/enable global setting to start.
Or create a vpn config before activating the vpn system!
Will fix that.
Logged In: YES
user_id=1082453
Originator: YES
Sorry Franck,
first of all - thank you for your time to answer anyway.
I do not agree to the closure of the case !
I had a busy phase, so I couldn't react on your response that fast.
My further investigations (with your hint on checking the sequence) brought this behaviour to light:
Activating VPN in VPNs tab (general settings) started the VPN service (PLUTO)
as expected up to release 1.4.13.
With 1.4.14 the rule was changed (and I personally do not agree to this change) in terms of PLUTO is only running when:
VPN in VPNs tab (general settings) is activated and a valid VPN tunnel is defined and also activated while booting.
This is a major decrease in functionality !!!
Here the reason why:
Imagine you have to support different customers and you want to do this remotely and secure by using VPN tunnels.
So you define several VPN tunnels to all these customers, but none of them is activated by default.
In earlier versions of IPCop you could just activate the wanted tunnel and it was up and running (without having to re-boot after activating one of the pre-defined "support-tunnels").
I would be very happy, if that behaviour came back in future IPCop releases !
Now the bad news:
I started with my lovely 1.4.13 release and with a pre-defined net-to-net VPN tunnel.
Tests have shown, that I could establish a VPN tunnel to a ZyWALL 10 device of an imaginary customer (pre-shared key, 3DES, MD5, DH2, no PfS).
Now with your sequence-hint in mind, I went through updates to 1.4.14, 1.4.15 and
last but not least to 1.4.16. With 1.4.16 even activating the VPN in VPNs (general setting), activating the VPN tunnel and after that, re-booting the IPCop will result in a VPN tunnel indicated as open, but no traffic at all can travel through that tunnel.
Logged In: YES
user_id=1082453
Originator: YES
Sorry Franck,
first of all - thank you for your time to answer anyway.
I do not agree to the closure of the case !
I had a busy phase, so I couldn't react on your response that fast.
My further investigations (with your hint on checking the sequence) brought this behaviour to light:
Activating VPN in VPNs tab (general settings) started the VPN service (PLUTO)
as expected up to release 1.4.13.
With 1.4.14 the rule was changed (and I personally do not agree to this change) in terms of PLUTO is only running when:
VPN in VPNs tab (general settings) is activated and a valid VPN tunnel is defined and also activated while booting.
This is a major decrease in functionality !!!
Here the reason why:
Imagine you have to support different customers and you want to do this remotely and secure by using VPN tunnels.
So you define several VPN tunnels to all these customers, but none of them is activated by default.
In earlier versions of IPCop you could just activate the wanted tunnel and it was up and running (without having to re-boot after activating one of the pre-defined "support-tunnels").
I would be very happy, if that behaviour came back in future IPCop releases !
Now the bad news:
I started with my lovely 1.4.13 release and with a pre-defined net-to-net VPN tunnel.
Tests have shown, that I could establish a VPN tunnel to a ZyWALL 10 device of an imaginary customer (pre-shared key, 3DES, MD5, DH2, no PfS).
Now with your sequence-hint in mind, I went through updates to 1.4.14, 1.4.15 and
last but not least to 1.4.16. With 1.4.16 even activating the VPN in VPNs (general setting), activating the VPN tunnel and after that, re-booting the IPCop will result in a VPN tunnel indicated as open, but no traffic at all can travel through that tunnel.
Logged In: YES
user_id=1041094
Originator: NO
Will fix that.
I think you missed that ;-)
You can download my latest IPCop build here* and check the fix.
-the first activated tunnel starts pluto & co
-the last instance downed also down pluto.
>IPCop will result in a VPN tunnel indicated as open, but no traffic at all
>can travel through that tunnel.
I have mounted this, and everything is ok.
You must find where is the problem yourself.
tcpdump on ipsec0, on RED...
A bug i'm aware of:
line 323 in vpnmain.cgi causes when GREEN is used as connection
point a problem to find %defaultroute
I always suppress this line because indicating locally what the remote side will use as gateway absolutly serve nothin except have the config files 'symetrics'.
*franck78.ath.cx
Logged In: YES
user_id=1082453
Originator: YES
Franck,
you are right, I misread your comment "Will fix that."
I will give your pre-1.4.17 release a try and I will let you know the results by this weekend.
Thank you for your patience !
Ralph
Logged In: YES
user_id=1082453
Originator: YES
Franck,
meanwhile I gave your pre-1.4.17 release a try.
Unfortunately it is still not behaving as expect:
Activating a tunnel doesn't bring the tunnel up (PLUTO down).
But if you enter and save the VPN config dialog after activating, the tunnel is up (PLUTO running). At least I don't need to re-boot to bring a tunnel up !
The problem I had with release 1.4.16 is related to the e100 NIC driver problem.
My Compaq Deskpro EN system has following NICs:
GREEN: 3Com "Corkscrew" EtherLink PCI III/XL, etc. (eth0)
ORANGE: Intel i82557/i82558 PCI EtherExpressPro (eth1) <- onboard
RED: RealTek RTL-8139 Fast Ethernet (eth2)
With release 1.4.16 the driver for the Intel e100 NIC was changed and will no longer be detected in my system.
This bug is reported in request ID 1762763 "new e100 not working".
I hope this will be fixed in 1.4.17 as well.
Logged In: YES
user_id=1041094
Originator: NO
>meanwhile I gave your pre-1.4.17 release a try.
>Unfortunately it is still not behaving as expect:
>Activating a tunnel doesn't bring the tunnel up (PLUTO down).
>But if you enter and save the VPN config dialog after activating, the
>tunnel is up (PLUTO running). At least I don't need to re-boot to bring a
>tunnel up !
For me it is logic. When the global setting is disabled, well it is disabled
even when you individually set/clear individual VPNs.
And I NEVER needed to reboot to active a VPN. In any version of ipsecctrl.
Just active vpn global setting and don't touch it.
Logged In: YES
user_id=1082453
Originator: YES
Hey !
I know how the behaviour of all releases up to 1.4.13. With 1.4.14 this behaviour is different now (decrease of functionality).
The global activation of VPN is a prerequisite (I know that).
I didn't touch it (after activating and re-booting the firewall) afterwards.
In other words my setting was:
Global VPN active and one or more VPN tunnels defined, but all set to inactive.
I expect the tunnel to come up after activating it (not needing to enter the configuration dialog and saving the not changed data).
In earlier releases after activating global VPN, PLUTO was running wether there were
defined VPN tunnels or not. I don't know for what reason somebody is trying hard to have PLUTO only running when at least one VPN tunnel is set to active along with the global VPN. I have no problem with that target but implement it correctly !
Could somebody please regression test the given scenarios below ?
Ralph
Logged In: YES
user_id=1870286
Originator: NO
I have a 1.4.16 fresh install, and my VPN works out fine to :
- DLINK DFL-200
- DLINK DI-804HV
Without a hassle, just had to make sure that the DI-804HV wasn't using any SHA1 !! - don't know if this is of any importance, but just wanted to share this...
Hi,
again an attemt to get the original VPN activation/deactivation behaviour back in.
Today I gave release 1.4.20 a try and still the "bug" is there ...
Up to release 1.4.13 you could have several VPN tunnels configured, all inactive
because they are used sporadically for support reasons. If you needed one or more
of those tunnels active, you could simply tick the active box and voila, the tunnel
was open. Since release 1.4.14 this behaviour is korrupted. You have to tick the
tunnel active and after that you have to go into the configuration dialog, change
something back and forth and save the config, after that, the tunnel is open.
Please double check the implementation changes from release 1.4.13 to 1.4.14.
Thanks !
I will look into this.
Might take some time though so please be patient.