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
MantisBT - Endian Firewall
View Issue Details
0001505Endian FirewallNetwork related (VPN, uplinks)public2008-12-09 20:542009-10-27 12:00
0001505: openvpn bridged mode not working anymore
openvpn 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.
needsfix, purple
child of 0001506closed peter-endian openvpn bridged mode should give possibility to select the zone to which it should bridge 
Issue History
2008-12-09 20:54peter-endianNew Issue
2008-12-09 20:54peter-endianAssigned To => peter-endian
2008-12-09 20:54peter-endianTag Attached: needsfix
2008-12-10 12:01peter-endianNote Added: 0001858
2008-12-10 14:21peter-endianIssue cloned: 0001506
2008-12-10 14:21peter-endianRelationship addedchild of 0001506
2008-12-10 14:21peter-endianStatusnew => resolved
2008-12-10 14:21peter-endianFixed in Version => 2.3
2008-12-10 14:21peter-endianResolutionopen => fixed
2009-05-20 16:48luca-endianNote Added: 0002367
2009-05-20 16:48luca-endianStatusresolved => feedback
2009-05-20 16:48luca-endianResolutionfixed => reopened
2009-05-20 17:12luca-endianNote Added: 0002368
2009-05-20 17:12luca-endianStatusfeedback => confirmed
2009-05-20 17:26luca-endianTag Attached: purple
2009-05-21 16:47peter-endianNote Added: 0002372
2009-05-22 16:06luca-endianNote Added: 0002376
2009-05-26 14:49peter-endianStatusconfirmed => resolved
2009-05-26 14:49peter-endianResolutionreopened => fixed
2009-05-26 16:51peter-endianStatusresolved => assigned
2009-05-26 17:20peter-endianNote Added: 0002381
2009-05-26 17:29peter-endianNote Added: 0002382
2009-05-26 17:41peter-endianNote Added: 0002383
2009-05-26 17:42peter-endianStatusassigned => resolved
2009-10-27 12:00peter-endianStatusresolved => closed

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.
2009-05-20 16:48   
I seems that on the client side tap is not bridged with br0 (green)
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!!!

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.
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.
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.
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
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