Hi all,
we have tested the new ccdfix-21-11-2012 version and i want to give some feedback. Alex you have solved pretty much of the before mentioned bugs, nice work. But we have found some smaller and one bigger problem.

smaller problems:
- If the server is running, there is the possibility to enter the "Static IP address pools" section but there can nothing be adjusted. There is the need to stop the server before something can be done in this area but nothing gives an evidence to this. So an idea can be to make it like in the "Advaced server options" where also a save button are present. Or another idea can be to leave a note that the server needs to be stopped for editing.

 
- If a wrong syntax for the route under "IPFire has access to these networks on the client´s site" was done e.g. "192.168.15/30" the error message gives a "Route invalid. (192.168.0.12/255.255.255.252)" back . So the error message gives a different/correct IP back.

- In the same section --> "IPFire has access to these networks on the client´s site" . If i use e.g. 192.168.150.0/30 for one client and i want to give another client 192.168.150.4/30 comes the error message which says that this route is already in use, this goes until x.x.x.7/30. If i take 192.168.150.8/30 i can use it again without problem for new clients. So one /30 subnet reserves an IP range from 0-8 .

The bigger problem:
We make a testing round in 3 IPFire zones, so there was green, orange and blue. We activated all zones over the "Client has access to these networks on IPFire´s site" and deleted every global additional routes in "Advanced server options" and the specific client could reach all zones behind IPFire so far so good. 
But as we used only orange, it was also possible for the client to reach all other zones again. So we tested it also with "None" Networks behind IPFire´s site but nevertheless the client could reach all 3 zones not only by pinging the targets, also by trying to login over SSH where the login shell was started.
The strange thing is that the server and client logs returns exactly from the WUI configured pushed routes.

First we thought this causes the IPTables rules for OpenVPN, but a test with a N2N connection contradicted this thinking. With N2N connections only the routes are reachable which are really configured in the .conf files respective which was configured over the WUI and which was shown by the log.

So at this time we are a bit clueless about whats happening there....

So far for the first from our site

Greetings

Erik

Am 23.11.2012 um 12:44 schrieb Michael Tremer:

I cannot merge your branch because of conflicts.

So here are some things that need to be fixed:

Rebase the branch to origin/next and please edit the commit messages,
which are just not helpful. Read this for a short introduction about
good commit messages:
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Translation strings must be:
 You are not able to save any changes while the OpenVPN server is running.
and
 Änderungen können nicht gespeichert werden, solange der OpenVPN-Server läuft.


Michael

On Wed, 2012-11-21 at 10:44 +0100, Alexander Marx wrote:

Dear List!

i fixed all Bugs which are known by now.

Changes are already in my Git repository, branch ccdfix.

Attached the package files which are tested on core 64.

Except the mtu-disc- bug all things are tested with Windows 7 and
linux mint12 client.
I found no more bugs. Please test it.

-- 


Alexander Marx


Fachinformatiker Systemintegration




_______________________________________________
Development mailing list
Development@lists.ipfire.org
http://lists.ipfire.org/mailman/listinfo/development

_______________________________________________
Development mailing list
Development@lists.ipfire.org
http://lists.ipfire.org/mailman/listinfo/development

_______________________________________________
Development mailing list
Development@lists.ipfire.org
http://lists.ipfire.org/mailman/listinfo/development