Topic: [ANNOUNCE] smeserver-openvpn-bridge-fws-1.1-2.rpm

[Daniel B.]

Hi. I think I've got an idea for fixing this issue.
Does this problem appears when you have a client connected to the VPN? or does it occures even if nobody is connected?
From what I've tested, it only occures when client are connected, so tap0 and br0 have some references still actives. If we try to delete br0 while these references are actives, it causes the error. The solution would be to kill each client session before shuting down. I'm currently writing the necessary script using the Net::OpenVPN::Manage module. I think it won't be too hard but I'll need some time to write it cleanly. Can anyone confirm that the problem only occures when client(s) is/are connected?

Cheers, Daniel

[Daniel B.]

You'll find on our website a new beta release of the contrib. I won't release version 1.1-3, but 1.2-0 as there's a lot of others changes:

- status page uses Net::OpenVPN::Manage to get the info, which allow real time infos and the possibility to disconnect the client you want
- the shutdown script disconnect all the client, this should prevent the unregister_netdevice waiting for br0 to become free etc... error
- Routes of local networks are pushed to the clients (patch from Jonathan Martens)
- the management interface is configured

To get the full changelog, install it and rpm -qi smeserver-openvpn-bridge.fws (testing environment recommended).

This new release now depend on the two perl modules Net::Telnet and Net::OpenVPN::Manage. You can find the two rpms, the contrib, and other dependences (openvpn, lzo, lzo2) here:

http://sme.firewall-services.com/downloads/smeserver-openvpn/rpms-beta/

[killerskippy]

You'll find on our website a new beta release of the contrib. I won't release version 1.1-3, but 1.2-0 as there's a lot of others changes:

- status page uses Net::OpenVPN::Manage to get the info, which allow real time infos and the possibility to disconnect the client you want
- the shutdown script disconnect all the client, this should prevent the unregister_netdevice waiting for br0 to become free etc... error
- Routes of local networks are pushed to the clients (patch from Jonathan Martens)
- the management interface is configured

To get the full changelog, install it and rpm -qi smeserver-openvpn-bridge.fws (testing environment recommended).

This new release now depend on the two perl modules Net::Telnet and Net::OpenVPN::Manage. You can find the two rpms, the contrib, and other dependences (openvpn, lzo, lzo2) here:

http://sme.firewall-services.com/downloads/smeserver-openvpn/rpms-beta/

Tested this with freesh install and i wish to report i still see this message

unregister_netdevice waiting for br0 to become free etc...

[okepc]

I noticed the following behaviour on my server.
When i needed to halt or reboot the server simply by command halt or reboot it will give me the unregister_netdevice waiting for br0 to become free error.
When i halt or reboot the server by signal-event reboot or signal-even halt it halts or reboots without the error.

Coincidence or ....

Regards

Dirk

[Daniel B.]

I'm not sure. I have it runing on my two personnal servers without problem. I have reboot it 2 or 3 times and I hadn't the unregister_netdevice problem. But I allways use the signal-event halt/reboot. I'd like to find a solution for this, but after googleling a while, it seems that a lot of people have this problem, and there's no real solution. If anyone has an idea ... I'd like to release this new version because it correct at least the dhcp bug, but each time you reboot the server freez, it's not very cool :/

By the way. Does it occures only when clients are connected ?

[okepc]

There were no clients connected at any time when i did the halts/reboots.

Regards

Dirk

[okepc]

It makes you think that maybe the solution lies in signal-event reboot/halt.

You and i didnt have any problems when shutting down or rebooting that way.

Regards

Dirk

[AndrewR]

Now that I have it working there are 3 things that I have not yet figured out - and have not been able to Google either:

1. When the subnet I'm on is the same as for the machine I establish the VPN connection with (e.g. 10.0.0.x), this seems to create problems in Windows. While wanting to access the modem on the VPN network, it points me to the (same) modem on the local network as they have identical IP addresses (e.g. 10.0.0.1). Is this normal behaviour?

2. After establishing a VPN connection I can map a network drive to my Windows PC. I can also browse the contents on the network drive and delete files etc. When trying to upload files, even small ones (0.5MB) I get the error message "Cannot copy .... Network drive no longer available" although I can still see the drive. Is there anything I can do to prevent this?

Thanks in advance!

Hi,

Just a couple notes on this:

Problems #1 and #2 are most definitely related. When you're making a virtual network connection, (which is exactly whan OVPN is doing), you can't make a connection to a network you're already a part of. The routing tables won't jive, and it won't work. Even if it says it's connected... it's lying. At the very least, you need to be trying from an entirely different subnet. And, more importantly.. the numbering of the two internal subnets MUST be different.

For example... let's say you're testing from home.

Home Network (private subnet): 10.0.0.x subnet
Office Network (private subnet): 10.0.0.x subnet

It won't work. One of those must be different. Honestly, a home network should never need to be on a 10.0.0.x subnet... no home network needs that many addresses. You can get by with a 192.168.x.x subnet, or, if you want to be different..and have almost as many addresses available as the office, use a 11.0.0.x subnet. The point is, it has to be different, so that your routing tables (which windows builds automatically, with help from the OVPN sw) can actually be done correctly. When you connect to the OVPN, it creates an entry which says "if you're going to address 10.0.0.x, then route through this tunnel / bridge we created. All others, go this way" Problem is.. if the virtual and real subnets are the same number, it gets confused.

Don't confuse windows.. it has a hard enough time as it is

[killerskippy]

I'm not sure. I have it runing on my two personnal servers without problem. I have reboot it 2 or 3 times and I hadn't the unregister_netdevice problem. But I allways use the signal-event halt/reboot. I'd like to find a solution for this, but after googleling a while, it seems that a lot of people have this problem, and there's no real solution. If anyone has an idea ... I'd like to release this new version because it correct at least the dhcp bug, but each time you reboot the server freez, it's not very cool :/

By the way. Does it occures only when clients are connected ?

I have my Test VPN server in this inviroment:

I have a subnet6 allowing me to have a number of usable public IP's

VPN server: 2 * nic's one on a public ip and other on a local 192.168.0.* server gateway mode

My work station is on a seperated network on range 192.168.1.* and is using a different gateway on a different public IP

I can connect, map network drives, browse, move files etc.......

I have tested shutdown and rebooting the server using:

shutdown -r now/shutdown -h now
signal-event reboot/signal-evet halt

Does not seem to matter if a user is connected or not it still wont work. Only option is to power route the box or hit the reset button

[jumba]

Well, first I would like to thank you all for a long good reading (yes, I really browsed through all the 21 pages in this thread!)

Now to my question:

I need to set up a transparent VPN-connection between two locations like this:

Code: [Select]

[OFFICE_1]<->[SMESERVER/GATEWAY_1]<->[INTERNET]<->[SMESERVER/GATEWAY_2]<->[OFFICE_2]
The main idea is that [SMESERVER/GATEWAY_1] should act as PDC for the clients in [OFFICE_1] as well as [OFFICE_2], but I think the clients in [OFFICE_2] would still receive their DHCP from [SMESERVER/GATEWAY_2].

So, adding the subnet used in [OFFICE_2] in "local natworks" in [SMESERVER/GATEWAY_1] should work, I think.

Now to the VPN-related issue:

In this thread, there is mentioned that smeserver-openvpn-bridge-fws COULD be used for setting up such a LAN2LAN connection between two Smeservers, but I cannot find any place where this is actually explained in more details.

Maybe I should start a new thread, since this thread doesn't seem to be very active any longer?

Or if someone has a ref to any more relevant place where this has been discussed I would of course be very grateful.
(I'm pretty sure I've seen this mentioned, but of course I cannot find it now when I need it...)

[pcowley]

I've just installed this contrib and rebooted.  When I first run it, it says Open VPN needs a master certificate.  I click on the "Create it" link and a form comes up "Generate the needed certificates for your server"

MAJOR ISSUE: When I complete the form and send it I get an error message "Bad caracteres in New Zealand at /etc/e-smith/web/panels/manager/cgi-bin/openvpn-bridge line 1364."

I have also tried an underscore instead of the space and tried putting "New Zealand" in quotes.  All are rejected with "bad character" error message and I can go no further.

I have logged this in the bug tracker

Cheers
Pete

[cactus]

MAJOR ISSUE: When I complete the form and send it I get an error message "Bad caracteres in New Zealand at /etc/e-smith/web/panels/manager/cgi-bin/openvpn-bridge line 1364."

I have also tried an underscore instead of the space and tried putting "New Zealand" in quotes.  All are rejected with "bad character" error message and I can go no further.

According to the regular expression on that line spaces and underscores are not allowed, try a dash as that should be allowed.

Code: [Select]

sub verif ($) {
        my ($string) = @_;
        if ($string =~ /^([-\@\w.]+)$/) {
        $string = $1;
        }
        else {
                die "Bad caracteres in $string";
        }
        return $string;
}

I have logged this in the bug tracker

Next time please report the bug number/link to the bug as well for easy reference: bug 3778. Also try to give your summary a more descriptive text, this would make it easier to people searching the bug tracker. Thank in advance.

[Franco]

Do yourself a favor:
DO NOT USE THIS CONTRIB!!!

Follow Knudsen's instructions and live happy without bugs.

[Daniel B.]

Hi everyone
I haven't worked on this contrib since a while as I don't have too much spare time. I know it would require more work.
For the underscore, maybe I could add it as an allowed character in a next release, for now try "new-zealand" (without quotes).

[stefan24]

Do yourself a favor:
DO NOT USE THIS CONTRIB!!!

Follow Knudsen's instructions and live happy without bugs.

I have installed the latest release version of the smeserver-openvpn-bridge-fws contrib on 4-5 SME servers so far and can access all of them without problems or bugs.

The OpenVPN solution following the instructions of Jesper Knudsen does *not* create a bridge connection (AFAIR), so I never could connect to another server on the same subnet, because routing did not work.
Additionally, certificates and keys are very easily created with the smeserver-openvpn-bridge-fws contrib.