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
Anonymous | Login | 2022-05-28 02:18 UTC | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001505 | Endian Firewall | Network related (VPN, uplinks) | public | 2008-12-09 20:54 | 2009-10-27 12:00 | ||||
Reporter | peter-endian | ||||||||
Assigned To | peter-endian | ||||||||
Priority | urgent | Severity | crash | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 2.2-rc3 | ||||||||
Target Version | Fixed in Version | 2.3 | |||||||
Summary | 0001505: openvpn bridged mode not working anymore | ||||||||
Description | 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. | ||||||||
Tags | needsfix, purple | ||||||||
Attached Files | |||||||||
![]() |
||||||
|
![]() |
|
(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 |
![]() |
|||
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 © 2000 - 2012 MantisBT Group |