Update to V9

it SHOULD be ok.  I would make a config backup and have the v9 iso handy just in case things go boom.

Well, I'm not a good person to ask - I'm too careful. [[;)]]

My theory is that you don't upgrade until there's a functional reason to do so.  On the unit with all of the IPsec tunnels and NATs, the reason to upgrade from V7 to V8 there is that V7 is no longer supported! [[;)]]  No point at all in going to V9 at present.

The story is a bit different when it comes to the other unit and the version of OpenVPN.  There might be some advantage in adding new users running Windows 7, but no effect on the existing users.  Here, too, I would vote to wait.

In any case, I would take William's advice to heart!

Cheers - Bob

I have 2 massive reasons to upgrade:

- 1:1 network NAT. We are waiting for this with much pain
- HTML Gateway

Do you use the http proxy with these boxes? If so, you should wait for 9.005 or you have to create an autorestart for the http proxy because it has a serious memory leak (it is diskussed somewhere here extensivly...). The normal networking features seem to work normal. I can't tell about IPS - do you use it?

V9.1 has a nice new function (ssl vpn profiles) - but 9.1 is early beta at time, so we will wait some more month for that.

A well planned fallback possibility should be in place - but I think in your dimensions thats clear standard.

The HTML Gateway seems to be a ressource hog - someone said, that it is not mentioned for hundreds of endusers but for few service accesses. What are your plans with that?

Regards
Manfred

Waiting for 9.005 is what I planned. We use the proxy.

The html gateway is not ready for massive usage, I have seen this in my tests. But we have some use cases where it would be helpful for now and in later versions it will be better I think.
IPS can't get worse than now...

On the other machine there are only IPSec and some SSL-tunnels - beside the usual firewall- and NAT-rules. Here I need the 1:1 NAT because some of our customers insist on their crude networks.. (like 192.168.1.0/24 or 10.0.0.0/24...)

A fallback strategy is a must, you are right. But a downtime of 1-2 hours is nothing I want to cause when there is a high risk.

I would like a Button continue/reset in the up2date process after the ha slave did the update and I can check if I want to update the master too or stop the update.

I guess you are now on 8.3xx. The option to keep a node on the previous version during up2date a ha system is introduced in v9. So my may was:

- break up ha, disconnect second node from networks
- install v9 on the second system up2date to desired version
- import backup from v8 running system
- test new system as far as possible without connection to real network
- shutdown v8 system and disconnect it from networks
- connect v9 system and start it

In case of a bigger desaster you can go back to v8 system. After some days you can install v9 on the standby system, up2date to the same version as the production system and create a ha system again.

I think starting with the vpn system would be my favorite - is less risky in my opinion.

Regards
Manfred

right now going to v9 is NOT recommended due to many memory leaks..at least.  Also v9 requires more ram and for what the OP is doing 4 gigs is the minimum even after the memory leaks are fixed...if you don't have appliances with 4 gigs..don't go to v9 under any circumstances.

Here I need the 1:1 NAT because some of our customers insist on their crude networks

If the Essential Firewall can do that, maybe you have a free way to do what you want - does that work?

HTML Gateway?  Why not simply a different Remote Access method?

Cheers - Bob