Opened 11 years ago

Closed 9 years ago

#261 closed Patch submission (fixed)

redirect-private fails when no route-gateway or ifconfig options specified

Reported by: guyyur Owned by: Gert Döring
Priority: minor Milestone: release 2.3.7
Component: Networking Version: OpenVPN 2.3.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

When specifying redirect-private option and not specifying route-gateway or ifconfig options, OpenVPN fails to add the route to the remote host with the following message:

NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing

In redirect_default_route_to_vpn() the check for remote endpoint happens even though it is not used by redirect-private.

Attachments (1)

redirect-private.patch (524 bytes) - added by guyyur 11 years ago.
Patch

Download all attachments as: .zip

Change History (14)

Changed 11 years ago by guyyur

Attachment: redirect-private.patch added

Patch

comment:1 Changed 10 years ago by Samuli Seppänen

Type: Bug / DefectPatch submission

Can someone review this patch and if it makes sense, merge it to Git?

comment:2 Changed 10 years ago by Gert Döring

Owner: set to Gert Döring
Status: newassigned

I'll try to find out what --redirect-private *does* and then I can go and fix it

comment:3 Changed 10 years ago by Gert Döring

Ummm. Guyyur, I'm not sure I get it. IPv4 routing inside OpenVPN needs a gateway address to route to - so if you are not using --ifconfig or --route-gateway, how does it work?

Can you provide a config example and a log file with your patch applied, please?

comment:4 Changed 9 years ago by Samuli Seppänen

guyyur: could you provide the information cron2 requests? Otherwise we will have to close this ticket as "invalid".

comment:5 Changed 9 years ago by guyyur

I was running bridge mode at the time.

The client runs dhclient on the tap device to get a local vpn address and route.
I was using --redirect-private to create the static route
for the --remote address which forwards to the pre-existing
default gateway.

I since moved to using route mode but I can setup a test environment
with the patch if needed.

client config example:
pull
dev tap
proto udp
remote HOSTNAME 1194
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
log /var/log/openvpn.log
comp-lzo

cipher AES-192-CBC

tls-client
ca ca.crt
cert cert.crt
key key.key
ns-cert-type server
remote-cert-tls server

redirect-private

server config example:
mode server
port 1194
dev tap0
keepalive 30 120
persist-key
persist-tun
user nobody
group nobody
verb 3
log /var/log/openvpn.log
comp-lzo

client-to-client
max-clients 10

cipher AES-192-CBC

tls-server
dh dh.pem
ca ca.crt
cert server.crt
key server.key
remote-cert-tls client

comment:6 Changed 9 years ago by Gert Döring

Aaah, tap mode, our eternal curse...

In route mode, things should "just work". In tap mode, not so - but I have no idea what happens with your patch and --redirect-private, to be honest - so a log would be appreciated (--verb 4).

Thanks in advance :-)

comment:7 Changed 9 years ago by guyyur

You can close this ticket as invalid.

I was looking for an option to just add the route to the openvpn server
which is step (1) of redirect-gateway without steps (2) and (3).

Based on the man page and the implementation "redirect-private"
does just that but the change log text for the option and its name
imply that it is intended to be used with pushed routes
which I wasn't using in bridge mode.

Log for OpenVPN 2.3.6 on FreeBSD 10.1 with patch applied
and with configuration similar to above below.
With the patch redirect_default_route_to_vpn will add the
route to the server even in bridge mode when redirect-private
option is specified.

relevant part of the log:
Thu May 28 22:31:18 2015 us=215002 UDPv4 link local: [undef]
Thu May 28 22:31:18 2015 us=215010 UDPv4 link remote: [AF_INET]192.0.2.2:1194
Thu May 28 22:31:18 2015 us=221430 TLS: Initial packet from [AF_INET]192.0.2.2:1194, sid=a508703d 2cc556b2
Thu May 28 22:31:18 2015 us=239757 VERIFY OK: depth=1, CN=CA, O=Test
Thu May 28 22:31:18 2015 us=240076 VERIFY OK: nsCertType=SERVER
Thu May 28 22:31:18 2015 us=240095 Validating certificate key usage
Thu May 28 22:31:18 2015 us=240103 ++ Certificate has key usage 00a0, expects 00a0
Thu May 28 22:31:18 2015 us=240121 VERIFY KU OK
Thu May 28 22:31:18 2015 us=240133 Validating certificate extended key usage
Thu May 28 22:31:18 2015 us=240143 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu May 28 22:31:18 2015 us=240150 VERIFY EKU OK
Thu May 28 22:31:18 2015 us=240158 VERIFY OK: depth=0, CN=Test Server
Thu May 28 22:31:18 2015 us=272506 Data Channel Encrypt: Cipher 'AES-192-CBC' initialized with 192 bit key
Thu May 28 22:31:18 2015 us=272528 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu May 28 22:31:18 2015 us=272540 Data Channel Decrypt: Cipher 'AES-192-CBC' initialized with 192 bit key
Thu May 28 22:31:18 2015 us=272562 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu May 28 22:31:18 2015 us=272584 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Thu May 28 22:31:18 2015 us=272600 [Test Server] Peer Connection Initiated with [AF_INET]192.0.2.2:1194
Thu May 28 22:31:20 2015 us=645103 SENT CONTROL [Test Server]: 'PUSH_REQUEST' (status=1)
Thu May 28 22:31:20 2015 us=649190 PUSH: Received control message: 'PUSH_REPLY,ping 30,ping-restart 120'
Thu May 28 22:31:20 2015 us=649223 OPTIONS IMPORT: timers and/or timeouts modified
Thu May 28 22:31:20 2015 us=649431 ROUTE_GATEWAY 198.51.100.70
Thu May 28 22:31:20 2015 us=650475 TUN/TAP device /dev/tap0 opened
Thu May 28 22:31:20 2015 us=650508 /sbin/route add -net 192.0.2.2 198.51.100.70 255.255.255.255
add net 192.0.2.2: gateway 198.51.100.70
Thu May 28 22:31:20 2015 us=655794 Initialization Sequence Completed

On closing:
Thu May 28 22:31:50 2015 us=908617 event_wait : Interrupted system call (code=4)
Thu May 28 22:31:50 2015 us=908863 TCP/UDP: Closing socket
Thu May 28 22:31:50 2015 us=908897 /sbin/route delete -net 192.0.2.2 198.51.100.70 255.255.255.255
delete net 192.0.2.2: gateway 198.51.100.70
Thu May 28 22:31:50 2015 us=909755 Closing TUN/TAP interface

comment:8 Changed 9 years ago by Gert Döring

Thanks for the log. I have done some reading of the code in the meantime, and while it might not be needed for you anymore, your patch still looks like a useful addition in case someone wants to use this option (for whatever reason, was there before I started contributing...)

comment:9 Changed 9 years ago by Gert Döring

So. Guyyur, if you want attribution for that patch as author, please let me know here or by mail to gert@… what I shall put in as realname and mail address into git...

comment:10 Changed 9 years ago by guyyur

realname: Guy Yur
mail address: guyyur@…

Thanks.

comment:11 Changed 9 years ago by Gert Döring

Milestone: release 2.3.7

comment:12 Changed 9 years ago by Gert Döring

At last...

Your patch has been applied to the master and release/2.3 branch.

commit 1e2b229e5140b784820906feb8446e47c1ecc62e (master)
commit 5502af840205a8a9342600385fcd4ef2919073ba (release/2.3)

Author: Guy Yur <guyyur@…>
Date: Mon Jun 1 21:51:13 2015 +0200

Fix --redirect-private in --dev tap mode.

comment:13 Changed 9 years ago by Gert Döring

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.