0001505: openvpn bridged mode not working anymore

(0001858)
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 openvpnbridge.py
- restructured openvpnbridge.py script, which now uses settingsfile
  class and creates debugging output. Implements apply and remove
  configuration
- openvpnbridge.py 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.

(0002367)
luca-endian (developer)
2009-05-20 16:48

I seems that on the client side tap is not bridged with br0 (green)

(0002368)
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)
br0: 192.168.0.15/24
OpenVPN account: gw-bridge nothing configured except for fixed ip: 192.168.0.100
Block DHCP responses coming from tunnel: yes

**chef** (OpenVPN client)
br0: 192.168.0.16/24
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
192.168.0.0 * 255.255.255.0 U 0 0 0 tap0
192.168.58.0 * 255.255.255.0 U 0 0 0 eth3
default 192.168.58.15 0.0.0.0 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:
DEVICE=tap
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
192.168.58.0 * 255.255.255.0 U 0 0 0 eth3
default 192.168.58.15 0.0.0.0 UG 0 0 0 eth3

If I add it by hand:
ip route add 192.168.0.0/24 dev br0

Now it works!!!

(0002372)
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.

(0002376)
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 openvpnbridge.py 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.

(0002381)
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.

(0002382)
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

(0002383)
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

Notes
(0001858) 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 openvpnbridge.py - restructured openvpnbridge.py script, which now uses settingsfile class and creates debugging output. Implements apply and remove configuration - openvpnbridge.py 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.

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

(0002368) 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) br0: 192.168.0.15/24 OpenVPN account: gw-bridge nothing configured except for fixed ip: 192.168.0.100 Block DHCP responses coming from tunnel: yes chef (OpenVPN client) br0: 192.168.0.16/24 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 192.168.0.0 * 255.255.255.0 U 0 0 0 tap0 192.168.58.0 * 255.255.255.0 U 0 0 0 eth3 default 192.168.58.15 0.0.0.0 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: DEVICE=tap 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 192.168.58.0 * 255.255.255.0 U 0 0 0 eth3 default 192.168.58.15 0.0.0.0 UG 0 0 0 eth3 If I add it by hand: ip route add 192.168.0.0/24 dev br0 Now it works!!!

(0002372) 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.

(0002376) 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 openvpnbridge.py 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.

(0002381) 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.

(0002382) 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

(0002383) 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

Please see now our new Bugtracker system: JIRA