SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0001505: openvpn bridged mode not working anymore - MantisBT Endian Bugtracker
Endian Issue Tracker

Please see now our new Bugtracker system: JIRA

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001505Endian FirewallNetwork related (VPN, uplinks)public2008-12-09 20:542009-10-27 12:00
Assigned Topeter-endian 
PlatformOSOS Version
Product Version2.2-rc3 
Target VersionFixed in Version2.3 
Summary0001505: openvpn bridged mode not working anymore
Descriptionopenvpn bridged mode does not join to the GREEN bridge anymore.
Configuration files changed and the script reads out from the wrong files.

Additionally to that, if it would join the bridge correctly, routing information cannot be applied when the openvpn tunnel restarts, since there is no more VPN endpoint ip address on the bridge device after the join. So pushed routing information cannot be applied because the gateway ip is not configured anymore.

The ip address from the tap device need to be moved to the bridge device after the join and moved back before --down

It would be nice to be able to select the zone of which bridge it should join. Since the effort to fix this problem is huge enough, this change could be easily added.
Tagsneedsfix, purple
Attached Files

- Relationships
child of 0001506closedpeter-endian openvpn bridged mode should give possibility to select the zone to which it should bridge 

-  Notes
peter-endian (administrator)
2008-12-10 12:01

- down script need to run before tap device closes, otherwise
  the tap device will not hold the ip address openvpn would like
  to remove during tap close.
- combine the bridge up and down script to a single python script
  since they do more or less the same. Trigger scripts become
  simple shell scripts which trigger
- restructured script, which now uses settingsfile
  class and creates debugging output. Implements apply and remove
- now moves the ip address from the tap device
  to its bridge in order not to break routing.
  Move the ip back to the tap device on down, in order to give
  openvpn the ip address back which it would like to remove.
luca-endian (developer)
2009-05-20 16:48

I seems that on the client side tap is not bridged with br0 (green)
luca-endian (developer)
2009-05-20 17:12

Test configurations:

OpenVPN and dhcp range accurately set to avoid any sort of overlap.
On both side dhcp is active.

**butters** (OpenVPN server)
OpenVPN account: gw-bridge nothing configured except for fixed ip:
Block DHCP responses coming from tunnel: yes

**chef** (OpenVPN client)
gw2gw connection options:
Connection type: Bridged
Block DHCP responses coming from tunnel:
Others are standard..

If I make the connection the server says connection is "established", client says it's "closed".

On the server side everything is fine.
On the client the tap interface is not bridged and there is a wrong route via tap, see below:

root@chef:/var/efw/openvpnclients/gw-bridged-to-butters # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface * U 0 0 0 tap0 * U 0 0 0 eth3
default UG 0 0 0 eth3

root@chef:/var/efw/openvpnclients/gw-bridged-to-butters # brctl showbridge name bridge id STP enabled interfaces
br0 0000.0060e0e25c57 no eth0

Looking through the /var/efw/openvpnclients/../settings I saw this line:
it should be tap0 (for my configurations)

I changed it by hand and now on the client gui connection is "established" (it's right)

tap0 device is added to br0 but these are the routes:

root@chef:/var/efw/openvpnclients/gw-bridged-to-butters # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface * U 0 0 0 eth3
default UG 0 0 0 eth3

If I add it by hand:
ip route add dev br0

Now it works!!!

peter-endian (administrator)
2009-05-21 16:47

problem is that on 2.2 the /var/efw/openvpn/default/settings file does not contain defauls settings for PURPLECLIENT_BEGIN_DEVICE, which is hardcoded to tap2

This will be written down by openvpn server gui, whenever one saves openvpn server settings. If the openvpn server settings has never been saved, that default setting is missing.
luca-endian (developer)
2009-05-22 16:06

After ran the OpenVPN server also on the client side one problem still exists:

If I disable the gw2gw connection the rule green subnet via br0 is removed.
This will cut off the green side of the firewall. :|

I think that this line in is pointless:
def removeConfig(conf):
run("ip route del %s dev %s 2>/dev/null"%(netcidr, conf['GREEN_DEV']))

I've removed it on my installation and then everything worked fine!!

I should try exactly what happens on 2.3 version.
peter-endian (administrator)
2009-05-26 17:20

that line is because on a bridged vpn endpoint, the routes which have been pushed by the openvpn server need to be added to the device where the tap device has been bridged to. openvpn installs routing and addresses on tap device. if the device is bridged these configuration need to be removed from the tap device and added to the bridge, in order to allow access to the vpn endpoint ip.

(the hardcoding to GREEN_DEV is wrong, btw. needs to be '$BRIDGE'_DEV)

when the vpn closes, this configuration needs to be removed from the bridge.
netcidr holds the subnet of the openvpn server, not of green.

can it be that in this case the local green and the remote green share the same subnet? then the local green would be removed, since they are same.
maybe a check would not be bad.
peter-endian (administrator)
2009-05-26 17:29

ok, that was bogus. it's been done correctly afterwards after the check if the vpn connection is bridged.

probably this line is simply to be removed.. i will check
peter-endian (administrator)
2009-05-26 17:41

ok, you are right. it makes no sense.
i will remove it.

it was about ip rules, which needed to be removed, because they were installed multiple times. routing entries can't be set up twice

- Issue History
Date Modified Username Field Change
2008-12-09 20:54 peter-endian New Issue
2008-12-09 20:54 peter-endian Assigned To => peter-endian
2008-12-09 20:54 peter-endian Tag Attached: needsfix
2008-12-10 12:01 peter-endian Note Added: 0001858
2008-12-10 14:21 peter-endian Issue cloned: 0001506
2008-12-10 14:21 peter-endian Relationship added child of 0001506
2008-12-10 14:21 peter-endian Status new => resolved
2008-12-10 14:21 peter-endian Fixed in Version => 2.3
2008-12-10 14:21 peter-endian Resolution open => fixed
2009-05-20 16:48 luca-endian Note Added: 0002367
2009-05-20 16:48 luca-endian Status resolved => feedback
2009-05-20 16:48 luca-endian Resolution fixed => reopened
2009-05-20 17:12 luca-endian Note Added: 0002368
2009-05-20 17:12 luca-endian Status feedback => confirmed
2009-05-20 17:26 luca-endian Tag Attached: purple
2009-05-21 16:47 peter-endian Note Added: 0002372
2009-05-22 16:06 luca-endian Note Added: 0002376
2009-05-26 14:49 peter-endian Status confirmed => resolved
2009-05-26 14:49 peter-endian Resolution reopened => fixed
2009-05-26 16:51 peter-endian Status resolved => assigned
2009-05-26 17:20 peter-endian Note Added: 0002381
2009-05-26 17:29 peter-endian Note Added: 0002382
2009-05-26 17:41 peter-endian Note Added: 0002383
2009-05-26 17:42 peter-endian Status assigned => resolved
2009-10-27 12:00 peter-endian Status resolved => closed

Copyright © 2005-2008 Endian, SRL. All rights reserved.

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker