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.
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
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
Am 23.11.2012 14:10, schrieb Erik K.:
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.
Fixed. There's now warning message, when someone opens the static network and server is running. it says: *ATTENTION:* You can only add new static networks when OpenVPN server is stopped.
on the other hand you are only able to edit the networknames, not the ip addresses..
- 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.
Yes, thats true. i rearranged the functions which validate the entries and it seems to be solved now.
- 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 .
That seems also related to the way, the functions where arranged. But there was no check if a new route collides with an already existing subnet. It was only checked, if a ip matches the given one. Fixed that and created a routine which checks subnets now.
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....
That is really strange! I am not able to test it because i have no physical server here, only one vm.
Did you check, if the ROUTES are deleted from server.conf when you changed the routing box? maybe another server restart is required after changing things here... Can you test that please? change one client to GREEN,ORANGE,BLUE and test. Then give him only ORANGE and RESTART server. Please also check, if there are routes in the server.conf!
Thank you very much for testing. A new package will follow shortly.
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
Am 23.11.2012 14:10, schrieb Erik K.:
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.
What did your test-environment look like? did you restart the client after changing the settings? I was not able to reproduce those strange problems. i tested with only green enabled and then switched to "none" but on my environment, it worked well.
i had a physical server at a dedicated line and another one on a DSL-Line.
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
-
Alexander Marx -
Erik K. -
Michael Tremer