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=8c877a82f6a63e07e2dde8d55... .
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.
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.
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.
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.
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
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.
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.
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=350f298025c...
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=a66e24bbfd0...
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=8c877a82f6a63e07e2dde8d55...
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