Opened 11 years ago

Closed 4 years ago

#336 closed Bug / Defect (wontfix)

--port-share doesn't work from 2.3.0 release

Reported by: reindeer Owned by: Gert Döring
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


When I use --port-share in my config and try to load web page firefox returns “SSL received a record that exceeded the maximum permissible length.”

$ telnet localhost 443
Trying ::1...
Connected to localhost.
Escape character is ']'.

$ telnet localhost 443
Trying ::1...
Connected to localhost.
Escape character is ']'.
?K5?6??f?qB-H???JۅtZRB??Connection closed by foreign host.

I mean I don't press any key but server sends some data

Change History (15)

comment:1 Changed 11 years ago by plaisthos

Can you share your server config? I cannot reproduce the issue.

comment:2 Changed 11 years ago by Samuli Seppänen

Resolution: invalid
Status: newclosed

comment:3 Changed 9 years ago by rherold

Resolution: invalid
Status: closedreopened


same probleme here with 2.3.8.

I have an open vpn tcp running on *:4443 and have configured a port share port-share 445 there is an apache running with ssl. If I connect directly to the apache no Problem. If I want do it via openvpn I got "WARNING: Bad encapsulated packet length from peer..." an an ssl error message in the browser: ssl_error_rx_record_too_long

lport 4443
port-share 443
proto tcp-server
proto tcp6-server
mode server
dev tun
push tun-ipv6
server-ipv6 XXXX:XXXX:XXXXX:XXXX::/64
ifconfig-pool-persist /etc/openvpn/static.txt 0
client-config-dir /etc/openvpn/ccd
auth-user-pass-verify /etc/openvpn/bin/ via-env
script-security 3 execve
topology subnet
mtu-disc maybe
keepalive 10 60
user openvpn
group openvpn
log-append /var/log/openvpn.log
verb 4
mute 10
dh keys/dh2048.pem
tls-auth keys/ta.key 0
ca keys/vpn.pem
cert keys/vpn.pem
key keys/vpn.pem

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

We'll investigate... we should not have broken it for 2.3 (because not much changed in the socket/proxy stuff there)...

Could you test with git master? The reason I'm asking: the socket and proxy handling code changed quite a lot - and if it happens to work again there, this might be an indication :-)

comment:5 Changed 9 years ago by rherold

git master works like without problem only change in the config was:

< script-security 3 execve

script-security 3

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

as discussed on IRC - we'll try to get it fixed in 2.3, but I'm not promising timelines... (OTOH, all the new goodness in git master means "you want that on the server anyway" :-) )

If you can manage to git --bisect the commit that broke it between 2.2. and 2.3.0, that would be even better - but it might not work out, as some of the commits produced non-working binaries on some platforms (nowadays, we take greater care...)

comment:7 in reply to:  description Changed 8 years ago by Christian Schrötter

Maybe it's releated: It looks like the port sharing feature isn't working when IPv6 is enabled. (tcp6-server mode)

Can anyone confirm this? Or is it another independent bug? Tested with 2.3.4 at Debian Jessie.

comment:8 Changed 8 years ago by plaisthos

I fixed a lot of ipv4 only features in master to be also v6. This could be one of them.

comment:9 in reply to:  8 Changed 8 years ago by Christian Schrötter

Indeed, fixed in git/master! Sorry for the noise…

comment:10 Changed 8 years ago by plaisthos

Resolution: wontfix
Status: reopenedclosed

No problem, thanks for confirming that it is working in master. I will set this to wontfix for 2.3. We might use error out instead.

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

Resolution: wontfix
Status: closedreopened

I actually have this still somewhere on my plate, to understand *why* it is failing in 2.3 - not promising any time lines ("if you want this feature today, use master") but I'm curious as there is nothing obvious... also I want to build a test rig to ensure we notice if we break this again.

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

Owner: set to Gert Döring
Status: reopenedaccepted

comment:13 Changed 8 years ago by hoene

We are using the port share feature.

Sometimes, especially in case of web socket traffic, the data is not forwarded timely, or not at all.

May, setting the TCP_NODELAY option or flushing the buffers more frequently, would help.

Version 0, edited 8 years ago by hoene (next)

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

So that it isn't lost (courtesy of @hoene) - an alternative approach is to use SSLH

comment:15 Changed 4 years ago by Gert Döring

Resolution: wontfix
Status: acceptedclosed

I am now closing this ticket.

2.3 is moving towards "end of life", and since this is working in 2.4 and 2.5 (which is about to be released in a few weeks), we are not going to invest time into finding out why it is broken in 2.3

The socket handling got rewritten massively for 2.4 (for dual-stack, preresolve and unified timers), so it's likely plaisthos accidentially fixed the issue while at it.

Apologies for taking so long to come to a definite statement :-)

Note: See TracTickets for help on using tickets.