From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Erik K." To: development@lists.ipfire.org Subject: Re: ccdfix-21-11-2012 Date: Fri, 23 Nov 2012 14:10:27 +0100 Message-ID: <25736D60-2B27-4115-9182-9A894D638D36@ipfire.org> In-Reply-To: <1353671054.14956.23.camel@rice-oxley.tremer.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8118360333022442232==" List-Id: --===============8118360333022442232== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, we have tested the new ccdfix-21-11-2012 version and i want to give some feed= back. Alex you have solved pretty much of the before mentioned bugs, nice wor= k. 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 t= o 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 serve= r options" where also a save button are present. Or another idea can be to le= ave 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=C2=B4s site" was done e.g. "192.168.15/30" the error message gi= ves a "Route invalid. (192.168.0.12/255.255.255.252)" back . So the error mes= sage gives a different/correct IP back. - In the same section --> "IPFire has access to these networks on the client= =C2=B4s site" . If i use e.g. 192.168.150.0/30 for one client and i want to g= ive another client 192.168.150.4/30 comes the error message which says that t= his route is already in use, this goes until x.x.x.7/30. If i take 192.168.15= 0.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 blu= e. We activated all zones over the "Client has access to these networks on IP= Fire=C2=B4s site" and deleted every global additional routes in "Advanced ser= ver options" and the specific client could reach all zones behind IPFire so f= ar so good.=20 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=C2= =B4s site but nevertheless the client could reach all 3 zones not only by pin= ging 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 ro= utes 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. >=20 > So here are some things that need to be fixed: >=20 > 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 >=20 > Translation strings must be: > You are not able to save any changes while the OpenVPN server is running. > and > =C3=84nderungen k=C3=B6nnen nicht gespeichert werden, solange der OpenVPN-= Server l=C3=A4uft. >=20 >=20 > Michael >=20 > On Wed, 2012-11-21 at 10:44 +0100, Alexander Marx wrote: >> Dear List! >>=20 >> i fixed all Bugs which are known by now. >>=20 >> Changes are already in my Git repository, branch ccdfix. >>=20 >> Attached the package files which are tested on core 64. >>=20 >> Except the mtu-disc- bug all things are tested with Windows 7 and >> linux mint12 client. >> I found no more bugs. Please test it. >>=20 >> --=20 >>=20 >>=20 >> Alexander Marx >>=20 >>=20 >> Fachinformatiker Systemintegration >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Development mailing list >> Development(a)lists.ipfire.org >> http://lists.ipfire.org/mailman/listinfo/development >=20 > _______________________________________________ > Development mailing list > Development(a)lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/development --===============8118360333022442232==--