From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Marx To: development@lists.ipfire.org Subject: Re: ccdfix-21-11-2012 Date: Sun, 25 Nov 2012 09:15:19 +0100 Message-ID: <50B1D397.6020404@oab.de> In-Reply-To: <25736D60-2B27-4115-9182-9A894D638D36@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2743835693358581347==" List-Id: --===============2743835693358581347== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 fe= edback. Alex you have solved pretty much of the before mentioned bugs, nice w= ork. 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 I= P 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 giv= es an evidence to this. So an idea can be to make it like in the "Advaced ser= ver 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 network= s on the client=C2=B4s 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 m= essage gives a different/correct IP back. > > - In the same section --> "IPFire has access to these networks on the clien= t=C2=B4s 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.1= 50.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 b= lue. We activated all zones over the "Client has access to these networks on = IPFire=C2=B4s site" and deleted every global additional routes in "Advanced s= erver 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 al= l 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 = pinging the targets, also by trying to login over SSH where the login shell w= as started. > The strange thing is that the server and client logs returns exactly from t= he WUI configured pushed routes. What did your test-environment look like? did you restart the client=20 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=20 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 wit= h a N2N connection contradicted this thinking. With N2N connections only the = routes are reachable which are really configured in the .conf files respectiv= e 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 >> =C3=84nderungen k=C3=B6nnen nicht gespeichert werden, solange der OpenVP= N-Server l=C3=A4uft. >> >> >> 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. >>> >>> --=20 >>> >>> >>> Alexander Marx >>> >>> >>> Fachinformatiker Systemintegration >>> >>> >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development(a)lists.ipfire.org >>> http://lists.ipfire.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development(a)lists.ipfire.org >> http://lists.ipfire.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development(a)lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/development --===============2743835693358581347==--