Hello,
i wanted also to report some bugs on the actual Final version from here --> http://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8c877a82f6a63e07e2dde8d55c6e0db4893bf73d . 

1) I was wondering that the "advanced client options" are also findable in the Net-to-Net section, cause the currently available N2N doesn´t support push or pull routing directives. N2N works in P2P Mode and is different to the Roadwarrior mode where a client server structure operates. 
Nevertheless it might be a nice feature to select more subnets over the WUI (should be made then with "route [IP] [subnet]" in the .conf file, but this should only be mentioned besides.

Fixed.
2) The converter script takes also affect to the existing Net-to-Net connections. But like above explained, the P2P mode does not work with typical server.conf directives and also not with a client-config-directory. 

Fixed.
3) In the Roadwarrior section "advanced client options" --> "Client has access to these networks on IPFire´s site" only the green network are displayed, but my testing environment includes also a blue network.

Fixed. was a bracket at wrong position
4) If a subnet will be pushed over the "Advanced server options" --> "Route push options" this subnet will be printed globally into the server.conf file so the "Client has access to these networks on IPFire´s site" does not take affect. 

That's not the whole truth.
You can set routes globally, right. These routes are pushed to all clients! (that's the sense of global options).
But you can have one route in global config and another one in the client. Then the client gets both routes.
You can mix settings as you like.

5) This point have also a context to the points 3) and 4) : In the section "advanced client options" --> "IPFire has access to these networks on the client ´s site" does not work. The following errors appears in the server log:

Nov 19 18:29:04 ipfire-server openvpnserver[7790]: /sbin/route add -net 192.168.150.1 netmask 255.255.255.252 gw 10.238.193.2
Nov 19 18:29:05 ipfire-server openvpnserver[7790]: ERROR: Linux route add command failed: external program exited with error status: 4

In that case the client was not reachable from server side. So the problem is that the "route [IP] [subnet]" directive are not printed into the server.conf. As in a previouse post mentioned, iroute needs a similar IP for the route entry in the server.conf . 
Example:
the ccd file have the following line:
iroute 192.168.150.0 255.255.255.0
the server.conf needs then also a
route 192.168.150.0 255.255.255.0
otherwise the kernel routing through the VPN does not work. 
Another point cause of the routing thing is that the push "route [IP] [subnet]" needs also to be in the server.conf . Currently it is written in the ccd file. In the test the following error messages appears in the log

Have you seen the wiki article about ccd extension? Sure you are not able to ping a clients network, as long as you fixed the client!
The client must have routing enabled (for windows look at the wiki, you need a registry key, for linux see wiki, you need to enable ip_forwarding) Then you are able to ping the clients network!

Nov 19 18:44:10 ipfire-server openvpnserver[26077]: aussi/84.30.xxx.xxx:39878 Options error: in --iroute 192.168.150.1 255.255.255.252 : Bad network/subnet specification
Nov 19 18:44:10 ipfire-server openvpnserver[26077]: aussi/84.30.xxx.xxx:39878 MULTI: Learn: 10.12.13.6 -> aussi/84.30.xxx.xxx:39878
so this points a problem out. If the push route [IP] [subnet] needs to be set globally in server.conf , there will be a problem with the "advanced client options" --> "Client has access to these networks on IPFire´s site" respectively to set a individually server site routing per client. Including the problem in point 3) and 4) the best way to bring up a way to choose specific networks behind the server for individual clients might be to manage this over IPTables (ovpnFW) i think. 

6) Another problem ( strange one) was, after a tunnel reconnect a Linux client (Fedora 17) wasn´t abel to reconnect. The server log shows only a
Nov 19 18:49:48 ipfire-server openvpnserver[26077]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
also a OpenVPN server stop and start could not retrieve the connection. I needed to restart the IPFire system to connect the Linux client again to the tunnel, this problem was reproducable. The strange thing was, this problem does not appear with a OS X system.
So after a longer while we could figure out that the new client directive "nobind" causes this problem. I deleted it and the reconnect works like a charm for both OS´s.

Will test it tomorrow
7) If i delete a client, his previously defined subnet are still present and not available for new connections. The error message is "This route (netzwerk behind client) is already in use. Beneath the little missing translation (netzwerk should be network ;-) the iroute entry in the ccdroute file under /var/ipfire/ovpn won´t be deleted if the complete client are deleted over the WUI. I did it then manually and could solve it in that way.

Will test tomorrow
So yesterday we could bring up a efficient OpenVPN connection but it tooks some time to figure the above mentioned problems out.

Greetings 

Erik


Am 20.11.2012 um 04:24 schrieb Alexander Marx:


Am 19.11.2012 21:47, schrieb Stefan Schantl:
Hello Alexander & Michael,

I've merged my mtu-disc changes with the ccd changes from Alexander.

http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=350f298025cf2f46ad9c25e4936e9aa9682ee452

Today, I was doing some testing and found some problems - mostly on the ccd extension:

* mtu-disc: The cgi doesn't respect if mtu-disc never has been configured.

   Fixed: http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=a66e24bbfd09b2ab2345ece2079d7143348a3980

* After creating a new ccd roadwarrior, there is very stange sting in the "/var/ipfire/ovpn/ccd/test" file:

   ifconfig-push 10.0.0.50 10.-1.255.49

   The first thing looks good, because I have assigned that IP to the connection, but the second part looks really strange.

WOW! That is really strange! i could not reproduce that. Tested with the same ip.
but the only possible killer is this code in general_functions:


sub getlastip
{
   my ($byte1,$byte2,$byte3,$byte4) = split (/\./,$_[0]);
   my $step=$_[1];
   for (my $x=$step;$x>=1;$x--){
       $byte4--;
       if($byte4==0){ $byte4=255;$byte3--;}
           if($byte3==0){$byte3=255;$byte2--;}
               if ($byte2==0){$byte2=255;$byte1--}
   }
   return "$byte1.$byte2.$byte3.$byte4";

your Prob seems that the code reduces byte 4, then byte3, then byte2 which leads to this "ip"
But as you can see in my code, i am checking if byte3 is EQUAL 0 and only then i set byte3 to 255 and reduce byte 2 .. ans so on.
Please check if you have the right general functions !

i appended it to this mail. Maybe i was too dumb to push all code to the git. it is in my ccd tree...

if you like i will send you the files via mail.

* In the WUI the Green Network always is selected, also if you have allowed access to more zones ( like blue or orange ) or to Nothing.

Well also here the same, i can not reproduce that error! It was right, that this behaviour was when we tested it. but then i fixed that error.

I append the ovpnmain.cgi at this mail. please check it.


Best regards,

Stefan

Am 16.11.2012 17:34, schrieb Michael Tremer:
Hello guys,

I merged the changes to the next branch.

http://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8c877a82f6a63e07e2dde8d55c6e0db4893bf73d

Please note, that this does not mean that testing is done. It has just
been started.

I also changed a lot of the translation strings. Fixed typos, rephrased
sentences. Please double check this.
Thanks for that, looks better.
Stevee will take care of the migration script. Please rename "lang.sh"
to "update-lang-cache" and put it in /usr/sbin (lfs/stage2).
Sorry, but i checket out next branch and lfs/stage2 is a script? How can i put the lang.sh (update-lang-cache) into it?



Michael

On Fri, 2012-11-16 at 06:19 +0100, Alexander Marx wrote:
Dear List!

Here you get the final release with latest modifications.
Git Version is updated.

Stevee, one thing for you:

We need to run an update script with the core update. The script is in
attachment, tools->ccd.pl
i don't know where to put it in the git branch, so please make it run
once on update.

This script looks for existing VPN Clients and builds ccd files with
default route to green network.
This is needed, because the default route to green is no longer in the
server.conf.
I modified the script so that there's no Console output.
The script needs to stop and start the OVPN server!

The lang.sh file should go to /usr/bin/ or /usr/local/bin/ in the next
release if possible. It makes it easier to generate the languages,
because one only needs to execute "lang.sh"

Here i also don't know where to put it in the git.



Thank you a lot for reviewing the code and testing.

Alex
_______________________________________________
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


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

<general-functions.pl><ovpnmain.cgi>_______________________________________________
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