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)
Change History (14)
Changed 11 years ago by
Attachment: | redirect-private.patch added |
---|
comment:1 Changed 10 years ago by
Type: | Bug / Defect → Patch submission |
---|
Can someone review this patch and if it makes sense, merge it to Git?
comment:2 Changed 10 years ago by
Owner: | set to Gert Döring |
---|---|
Status: | new → assigned |
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
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
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
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
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
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
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
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:11 Changed 9 years ago by
Milestone: | → release 2.3.7 |
---|
comment:12 Changed 9 years ago by
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
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Patch