Your message dated Thu, 23 Jul 2009 13:29:53 +0200
with message-id <[email protected]>
and subject line Problem solved by submitter and solution in upstream code not
possible
has caused the Debian Bug report #417934,
regarding should add explicit route to openvpn peer
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
417934: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417934
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: openvpn
Version: 2.0.9-4
Severity: wishlist
We are running OpenVPN on a company gateway. The company has a /24
network, e.g. 1.2.3.0/24, and the gateway is at 1.2.3.1. It uses
push "route 1.2.3.0 255.255.255.0"
in the server configuration to ensure that all traffic from road
warriors to the company network goes via the tunnel.
Unfortunately, this also causes the OpenVPN traffic itself to be
sent through the tunnel:
10.130.60.5 dev tun0 proto kernel scope link src 10.130.60.6
10.130.60.1 via 10.130.60.5 dev tun0
1.2.3.0/24 via 10.130.60.5 dev tun0
84.72.xx.0/20 dev wan proto kernel scope link src 84.72.xx.xxx
default via 84.72.xx.1 dev wan
As you can see, traffic to 1.2.3.1 will be routed via tun0, the
OpenVPN interface.
The solution is obviously to add an explicit /32 route for all
peers, just like it is done when
push "redirect-gateway"
is given on the server side. Since there are no negative side
effects I can think of, I suggest making OpenVPN always add explicit
/32 routes via the default gateway to its peers, on the server *and*
on the client side.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
--
.''`. martin f. krafft <[email protected]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
--- End Message ---
--- Begin Message ---
Hi Martin,
I'm closing this bug since you already have a solution and 'suggest
making OpenVPN always add explicit /32 routes via the default gateway
to its peers, on the server *and* on the client side.' is not a good
idea, since sometimes the connection to the VPN peer is not done through
the default gw, but using another link/interface.
Thanks,
Alberto
--
Alberto Gonzalez Iniesta | Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred | http://inittab.com
Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
--- End Message ---
