Dear List!
I tried to fix the Bugs that Erik had and i adapted the code to michaels suggestions. As i learned from the last mails, my code is far away from being used and finding your acceptance. So please take some time to test it again.
Michael: I know the layout of the Roadwarrior side is not good. But when putting "redirect gateway" and "net to route" beneath each other, it looks quite not good. Maybe you have a suggestion for me ;-)
As always i appreciate your comments.
Alexander Marx
Fachinformatiker Systemintegration
Replying to this mail, but actually took the code from the later one.
On Tue, 2012-10-30 at 15:29 +0100, Alexander Marx wrote:
Michael: I know the layout of the Roadwarrior side is not good. But when putting "redirect gateway" and "net to route" beneath each other, it looks quite not good. Maybe you have a suggestion for me ;-)
The layout of the "add net" page is a but better. Things that are to fix though are: Labels of input are on the left and not above. Again, there are spelling errors and there is no such word as "ip pool". It's actually "IP address pool". When editing a subnet, the submit button is suddenly on the left. Hitting it causes a "net already exists" error.
The roadwarrior client page looks much better now, although there are still spelling mistakes in the English version. The alignment of the data in the table differs from column to column.
See my last mail about the "net to route" box.
I would put those options in a grid layout as it has been done on the "advanced options" page. Headlines indicate what kind of options you can expect there.
Michael
Replying to this mail, but actually took the code from the later one.
On Tue, 2012-10-30 at 15:29 +0100, Alexander Marx wrote:
Michael: I know the layout of the Roadwarrior side is not good. But when putting "redirect gateway" and "net to route" beneath each other, it looks quite not good. Maybe you have a suggestion for me ;-)
The layout of the "add net" page is a but better. Things that are to fix though are: Labels of input are on the left and not above. Again, there are spelling errors and there is no such word as "ip pool". It's actually "IP address pool". When editing a subnet, the submit button is suddenly on the left. Hitting it causes a "net already exists" error.
These things are fixed now.
The roadwarrior client page looks much better now, although there are still spelling mistakes in the English version. The alignment of the data in the table differs from column to column.
Well all columns except the subnet dropdownfield are aligned left. I adapted the dropdownfield to align left also.
See my last mail about the "net to route" box.
Here we get into trouble. I am actually trying to fix this but come over an issue: Sure it is possible to enter more than one route (although i am not sure about the sense). But this is only usable for CCD Clients! We are not able to use this textbox for dynamic addressed hosts, because the openvpn site says that these features are only for ccd clients. Please correct me if i am wrong. But after reading a few pages i came to the end that if you want to push routes to dynamic addressed clients, the route options have to be in the server.conf. That leads to the problem, that all dynamic clients get the same routes which is not useful.
here i am stuck and can not go on. If i use a textbox, people are able to enter routes in the box even though they checked "dynamic addresspool from ovpn server". This is because of the fact that i do NOT know, which option is checked at the time the page opens.
I need assistance at this point.
I would put those options in a grid layout as it has been done on the "advanced options" page. Headlines indicate what kind of options you can expect there.
Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Another thing i came across is that you pointed out all submitbuttons have to be on the right. Here i have another question:
Why is the button "add" on the mainpage (for adding new clients) on the left under the table with all vpn-connections?? And why is the "save" and "cancel" button on the site where you can add a new connection centerd under the certificate part?
Should i adapt them?
Alex
Hello Alexander, so i have looked to your fixed bugs which i mentioned regarding to the ccd content. So you made pretty much of it but i have found some things which i want to report as soon as possible.
Now the ccd file are filled up with his explicit directives but there seems to be some issues.
- The "ifconfig-push" directive have a syntax like "ifconfig-push [server] [client]" the WUI displays only the Client IP in the flip menu of the "Host address" column, but it appears x.x.x.6 in the WUI (for the Client) which is correct but the ccd file wrote x.x.x.6 as the first IP which should be the server IP and not the client IP. So i think the IP´s for ifconfig-push should be reversed.
- The static IP Pool aren´t in the right order so the ccd content shows me "ifconfig-push x.x.x6 x.x.x.9" for the first connection. So ifconfig-push should give as the first IP the server IP, the second IP is reserved for the client. The order in a /30 subnet (which should give the compatibility for Windows TAP-Win32 adapter driver) are normally [5, 6] [9, 10] [13, 14] and so on. So the a connection can look e.g. like this "ifconfig-push x.x.x5 x.x.x6" and so on. A good explanation can be found on OpenVPN documentation --> http://openvpn.net/index.php/open-source/documentation/howto.html#policy . Suggestion: if there are networks without Windows clients, there is no need to take a /30 subnet. In this case "--topology p2p" should disables the "--topology net30" mode. But i think to implement both possibilities in code is may too much effort for a small benefit (more subnet space but also more complicated to understand the configuration) .
- If i apply a second connection and i use the same IP´s which are provided by the WUI (Host addresses and the flip menu) both connections becomes the same IP´s for server and client. So i think this leads to connection problems cause every connection needs an own virtual address pair for the server and client tunnel IP endpoints. Suggestion: As i wrote in a previous mail, if a chosen IP is already in use possibly a plausicheck can give an error message back e.g. "this IP is already in use" or something, it can be bulky to find a free address pair by a wide range of clients. So a possible solution can be to delete existing IP´s from the flip menu of the Host addresses column so it is more transparent for the users which IP´s can be used.
- A question for myself and of course to you ;-) : Is "redirect-gateway" the best solution or is may "redirect-gateway def1" a better one ? I have heard about some problems in case of UMTS connections where "redirect-gateway" sometimes doesn´t work and "redirect-gateway def1" was favored in that case, but i´am not sure about that.
- Another suggestion for the comments in ccd: Currently there is a comment line "#All traffic is redirected through the vpn" may be a better choice can be "#All IP traffic is redirected through the vpn" because IPFire provides only a routed OpenVPN and so there is no possibility for transfering e.b. broadcast etc. packets.
A question: How do you want to integrate the OpenVPN firewall, will it takes place on ovpnmain.cgi , or do you want to make an own FW configuration page ?
So far for now
Greetings Erik
Am 30.10.2012 um 15:29 schrieb Alexander Marx:
Dear List!
I tried to fix the Bugs that Erik had and i adapted the code to michaels suggestions. As i learned from the last mails, my code is far away from being used and finding your acceptance. So please take some time to test it again.
Michael: I know the layout of the Roadwarrior side is not good. But when putting "redirect gateway" and "net to route" beneath each other, it looks quite not good. Maybe you have a suggestion for me ;-)
As always i appreciate your comments.
Alexander Marx Fachinformatiker Systemintegration
<Marx-ccd-30.10.12.tar.gz>_______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development