Bug 1013178

Summary:	vpnc bind to local-address flawed
Product:	[Fedora] Fedora	Reporter:	JW <ohtmvyyn>
Component:	vpnc	Assignee:	Felix Schwarz <fschwarz>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	chkr, fschwarz, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-09 22:27:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description JW 2013-09-28 00:39:03 UTC

Description of problem:
The --local-addr implementation is flawed

Version-Release number of selected component (if applicable):
vpnc-0.5.3

How reproducible:
Always

Steps to Reproduce:
1. on multi-interface host run vpnc with --local-addr set to, say, IP of second interface
2. ip route show
3. ip link show

Actual results:
2. route has been added over the wrong (eg first) interface
3. mtu has been derived from the wrong (eg first) interface

Expected results:
2. added route should be over same device as device for bind IP
3. mtu should also be derived from the correct device

Additional info:
Some of the problems are in /etc/vpnc/vpnc-script.
When adding the route the current default route is always used as a template.
And when working out correct MTU to use the default interface is also always used.
Instead vpnc should be exporting something like VPNLOCALADDR to the script environment (would default to 0.0.0.0) so that vpnc-script can choose the correct interface device for both the route and the mtu calculation.

Comment 1 Felix Schwarz 2014-11-10 09:37:00 UTC

Thank you very much for reporting. I'm sorry that you didn't get a response earlier but unfortunately this happens sometimes as many Fedora developers are just volunteers which have other time constraints.

I just pushed a new vpnc version to updates-testing (for Fedora 20 and 21). Can you please check if the problem still happens with Fedora 20 + the latest vpnc package (vpnc-0.5.3-XX.svn550)? If so, please mention this in this report and I'll try to debug the issue.

If the issue is gone or you are not interested in this capability anymore please let us know so we can close the bug.

Comment 2 Felix Schwarz 2014-11-16 17:07:48 UTC

I think the bug might still be present in the latest vpnc-script as shipped in vpnc 0.5.3-22.svn550.fc20. Can you please confirm that?

The good news is that vpnc-script was split of from the main vpnc project and the new maintainer (David Woodhouse) should be much more easy to work with (http://git.infradead.org/users/dwmw2/vpnc-scripts.git/). If your issue is still present I suggest you report the bug to him as we (in Fedora) don't have the required manpower to develop vpnc(-script) fixes on our own.

If the vpnc-script contains a fix for your issue, feel free to ping us. Personally I'd be happy to include such a patch once it has been accepted upstream.

Comment 3 Felix Schwarz 2014-12-09 22:27:07 UTC

I'm trying to keep the bug lists manageable so I'm closing this one because of missing feedback.

JW: Thank you very much for your bug report. Feel free to reopen the bug at any time.

Comment 4 JW 2014-12-09 22:44:58 UTC

I will not be providing any more feedback or bugs because of the systemd monstrosity has totally destroyed my interest in Fedora/RedHat.

Comment 5 Felix Schwarz 2014-12-09 22:52:46 UTC

fair enough. Thank you anyway for your quick response.