[Openvpn-users] client config fallback from 1194 udp to 80 tcp

[Stefan Szabo]

hi to you all,
does anyone knows how it’s possible to put in client config declarations to fallback from udp port 1194 to tcp port 80?in case i’m in a place where udp is filtered to be able to conect over tcp 80.
i tried all the possibilities but nothing seems to work for me.i tested with tunnelblick, are this options openvpn client dependent?
<connection>
remote x.x.x.x
port 80
proto tcp
</connection>
<connection>
remote x.x.x.x
port 1194
proto udp
</connection>…...
thanks!

------------------------------------------------------------------------------

[d***@gmail.com]

Hi,

First: do you have two server instances listening on both proto/port
combinations ?

Second: Your config will cycle through each connection block until it
connects
(presuming you do not use --remote-random)

A MUCH more appropriate solution would be to have TWO separate config files
and use them as and when appropriate. IE Manual Fallback ...

NOTE: Just because you specify HTTP port 80 does not mean an intervening
firewall is not capable of detecting a NON HTTP protocol and blocking you
anyway.

regards


----- Original Message -----
From: "Stefan Szabo" <***@rcs-rds.ro>
To: <openvpn-***@lists.sourceforge.net>
Sent: Tuesday, October 20, 2015 8:58 PM
Subject: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Stefan Szabo

hi to you all,
does anyone knows how it’s possible to put in client config declarations
to fallback from udp port 1194 to tcp port 80?in case i’m in a place
where udp is filtered to be able to conect over tcp 80.
i tried all the possibilities but nothing seems to work for me.i tested
with tunnelblick, are this options openvpn client dependent?
<connection>
remote x.x.x.x
port 80
proto tcp
</connection>
<connection>
remote x.x.x.x
port 1194
proto udp
</connection>…...
thanks!

------------------------------------------------------------------------------
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

------------------------------------------------------------------------------

[Jason Haar]

Post by d***@gmail.com
NOTE: Just because you specify HTTP port 80 does not mean an intervening
firewall is not capable of detecting a NON HTTP protocol and blocking you
anyway.

I agree - in fact I'd suggest NEVER use tcp/80 and instead use tcp/443 -
as that's just as likely to be open and you are less likely to hit a
transparent proxy

Also, you had tcp/80 first and then udp/1194 - which I think is the
opposite order to what you wanted? ie openvpn works from the top of the
config downwards
--
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: [phone]
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1


------------------------------------------------------------------------------

[Stefan Szabo]

yes i know all that, this is just for testing purpose, the final it wiil be udp and then tcp.

good point about 80 tcp,and yes i will use 443 tcp wich is more likely not to be intercepted

my question is why is not function the fallback mechanism from the cfg file, in my case the client continously use only port 80 tcp even if this port is DROP or REJECT with iptables on openvpn server.
and also if i have two different openservers listen on the same port lets say 1194 udp, when the first is down, it will not jump on the second one.

remote X 1194
remote Y 1194

when i click connect every time is going to the first and not jump to the secondone, i tested also with randome declaration, but even with random is not a solutions depends on wich one is take first.

a solution is of course with two separate configs, but not all users have technical skills and for ordinary people is hard to explain: if first is not working try second.what if you have 4 servers and 4 ports?

now we are doing round robin DNS fallback with two servers and two ports(udp, tcp).

and yes i have a server which know listens on 1194-udp and 80-tcp.

Thanks for the answers.

Post by Jason Haar

Post by d***@gmail.com
NOTE: Just because you specify HTTP port 80 does not mean an intervening
firewall is not capable of detecting a NON HTTP protocol and blocking you
anyway.

I agree - in fact I'd suggest NEVER use tcp/80 and instead use tcp/443 -
as that's just as likely to be open and you are less likely to hit a
transparent proxy
Also, you had tcp/80 first and then udp/1194 - which I think is the
opposite order to what you wanted? ie openvpn works from the top of the
config downwards
--
Cheers
Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: [phone]
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
------------------------------------------------------------------------------
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

------------------------------------------------------------------------------

[Gert Doering]

Hi,

Post by Stefan Szabo
my question is why is not function the fallback mechanism from the cfg file, in my case the client continously use only port 80 tcp even if this port is DROP or REJECT with iptables on openvpn server.

This works for me :-) - but since you have neither told us which version
of OpenVPN you are using nor provided a log (--verb 4), it's somewhat
hard to be more specific.

Post by Stefan Szabo
and also if i have two different openservers listen on the same port lets say 1194 udp, when the first is down, it will not jump on the second one.
remote X 1194
remote Y 1194

Again, "works for me" (and everyone else)

gert

[Stefan Szabo]

openvpn server: OpenVPN 2.3.8 x86_64-redhat-linux-gnu
openvpn client: Tunnelblick 3.6beta10 (build 4400)

config client:

<connection>
remote 62.231.75.XX
port 80
proto tcp wait 1
</connection>
<connection>
remote 62.231.75.XX
port 1194
proto udp wait 10
</connection>

client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
cipher AES-128-CBC
verb 3
auth-user-pass
comp-lzo








.etc

on my server in iptables reject all tcp from my source, in order to test the fallback

in tunnelblick logs:

2015-10-21 10:19:05 TCPv4_CLIENT link remote: [AF_INET]62.231.75.XX:80
2015-10-21 10:19:05 MANAGEMENT: >STATE:1445411945,WAIT,,,
2015-10-21 10:19:05 Connection reset, restarting [0]

and this is on and on, repeating.always choose 80 tcp, never jumps on udp 1194

Post by Gert Doering
Hi,

Post by Stefan Szabo
my question is why is not function the fallback mechanism from the cfg file, in my case the client continously use only port 80 tcp even if this port is DROP or REJECT with iptables on openvpn server.

This works for me :-) - but since you have neither told us which version
of OpenVPN you are using nor provided a log (--verb 4), it's somewhat
hard to be more specific.

Post by Stefan Szabo
and also if i have two different openservers listen on the same port lets say 1194 udp, when the first is down, it will not jump on the second one.
remote X 1194
remote Y 1194

Again, "works for me" (and everyone else)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/

[d***@gmail.com]

Hi

----- Original Message -----
From: "Stefan Szabo" <***@rcs-rds.ro>
To: "Gert Doering" <***@greenie.muc.de>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Wednesday, October 21, 2015 8:21 AM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Stefan Szabo
openvpn server: OpenVPN 2.3.8 x86_64-redhat-linux-gnu
openvpn client: Tunnelblick 3.6beta10 (build 4400)
<connection>
remote 62.231.75.XX
port 80
proto tcp wait 1
</connection>
<connection>
remote 62.231.75.XX
port 1194
proto udp wait 10
</connection>

This works as it should for me:

CLIENT CONFIG:
<connection>
remote NAME
port 80
#proto tcp wait 10
proto tcp .. and other options are not parsed
</connection>
<connection>
remote SAME NAME
port 1194
#proto udp wait 10
proto udp .. and other options are not parsed
</connection>

LOG:
Wed Oct 21 13:26:39 2015 us=921442 OpenVPN 2.3.8 i486-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Wed Oct 21 13:26:39 2015 us=922386 library versions: OpenSSL 1.0.1k 8 Jan
2015, LZO 2.08

<snip>

Wed Oct 21 13:26:40 2015 us=112379 Attempting to establish TCP connection
with [AF_INET]xx.xx.xx.xx:37085 [nonblock]
Wed Oct 21 13:26:50 2015 us=139124 TCP: connect to [AF_INET]xx.xx.xx.xx:80
failed, will try again in 5 seconds: Connection timed out
Wed Oct 21 13:26:50 2015 us=140821 SIGUSR1[soft,init_instance] received,
process restarting
Wed Oct 21 13:26:50 2015 us=141197 Restart pause, 5 second(s)

<snip>

Wed Oct 21 13:26:55 2015 us=175752 UDPv4 link remote:
[AF_INET]xx.xx.xx.xx:1194
Wed Oct 21 13:26:55 2015 us=196439 TLS: Initial packet from
[AF_INET]xx.xx.xx.xx:1194, sid=565ee489 80afc503

<snip>

Wed Oct 21 13:26:55 2015 us=656023 [...] Peer Connection Initiated with
[AF_INET]xx.xx.xx.xx:1194
Wed Oct 21 13:26:58 2015 us=123524 SENT CONTROL [...]: 'PUSH_REQUEST'
(status=1)
Wed Oct 21 13:26:58 2015 us=128551 PUSH: Received control message:
'PUSH_REPLY,{redacted},ifconfig 10.105.101.74 255.255.255.0,peer-id 0'

[Is this a bug .. ?]
Wed Oct 21 13:26:58 2015 us=129086 Option 'explicit-exit-notify' in
[PUSH-OPTIONS]:3 is ignored by previous <connection> blocks

Wed Oct 21 13:26:58 2015 us=129494 OPTIONS IMPORT: timers and/or timeouts
modified
Wed Oct 21 13:26:58 2015 us=129606 OPTIONS IMPORT: explicit notify parm(s)
modified
Wed Oct 21 13:26:58 2015 us=129713 OPTIONS IMPORT: --ifconfig/up options
modified
Wed Oct 21 13:26:58 2015 us=129846 OPTIONS IMPORT: route options modified
Wed Oct 21 13:26:58 2015 us=130167 OPTIONS IMPORT: route-related options
modified
Wed Oct 21 13:26:58 2015 us=130313 OPTIONS IMPORT: environment modified
Wed Oct 21 13:26:58 2015 us=130418 OPTIONS IMPORT: peer-id set
Wed Oct 21 13:26:58 2015 us=130524 OPTIONS IMPORT: adjusting link_mtu to
1605
Wed Oct 21 13:26:58 2015 us=159018 TUN/TAP device tun86 opened
Wed Oct 21 13:26:58 2015 us=159282 TUN/TAP TX queue length set to 100
Wed Oct 21 13:26:58 2015 us=159502 do_ifconfig, tt->ipv6=0,
tt->did_ifconfig_ipv6_setup=0
Wed Oct 21 13:26:58 2015 us=159707 /sbin/ifconfig tun86 10.105.101.74
netmask 255.255.255.0 mtu 1500 broadcast 10.105.101.255
Wed Oct 21 13:26:58 2015 us=257649 /sbin/route add -net xx.xx.xx.xx netmask
255.255.255.255 gw 172.17.2.1

<snip>

Wed Oct 21 13:26:58 2015 us=411079 Initialization Sequence Completed

Regards


------------------------------------------------------------------------------

[Stefan Szabo]

hi,

without proto tcp declaration it doesnt try over tcp, all that is doing is udp.

if the first line is proto tcp, the first connection is over tcp, after that jumps over UDP.UDP is tried for 5 times after that it resets from the beginning.
the second declaration for remote is not parsed, it only tryes the first one.
i tested both windows7(openvpn gui v4) and mac os(tunnelblick).

Wed Oct 21 16:35:46 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 21 16:35:47 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Oct 21 16:35:47 2015 Attempting to establish TCP connection with [AF_INET]62.231.75.xx:80
Wed Oct 21 16:35:47 2015 MANAGEMENT: >STATE:1445434547,TCP_CONNECT,,,
Wed Oct 21 16:35:47 2015 TCP connection established with [AF_INET]62.231.75.xx:80
Wed Oct 21 16:35:47 2015 TCPv4_CLIENT link local: [undef]
Wed Oct 21 16:35:47 2015 TCPv4_CLIENT link remote: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:35:47 2015 MANAGEMENT: >STATE:1445434547,WAIT,,,
Wed Oct 21 16:36:32 2015 Connection reset, restarting [-1]
Wed Oct 21 16:36:32 2015 SIGUSR1[soft,connection-reset] received, process restarting
Wed Oct 21 16:36:32 2015 MANAGEMENT: >STATE:1445434592,RECONNECTING,connection-reset,,
Wed Oct 21 16:36:32 2015 Restart pause, 5 second(s)
Wed Oct 21 16:36:37 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 21 16:36:37 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Oct 21 16:36:37 2015 TCP/UDP: Preserving recently used remote address: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:36:37 2015 UDPv4 link local (bound): [undef]
Wed Oct 21 16:36:37 2015 UDPv4 link remote: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:36:37 2015 MANAGEMENT: >STATE:1445434597,WAIT,,,
Wed Oct 21 16:36:37 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:36:39 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:36:43 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:36:52 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:37:08 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:37:37 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Oct 21 16:37:37 2015 TLS Error: TLS handshake failed
Wed Oct 21 16:37:37 2015 SIGUSR1[soft,tls-error] received, process restarting
Wed Oct 21 16:37:37 2015 MANAGEMENT: >STATE:1445434657,RECONNECTING,tls-error,,
Wed Oct 21 16:37:37 2015 Restart pause, 2 second(s)
Wed Oct 21 16:37:39 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 21 16:37:39 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Oct 21 16:37:39 2015 TCP/UDP: Preserving recently used remote address: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:37:39 2015 Attempting to establish TCP connection with [AF_INET]62.231.75.xx:80

Post by d***@gmail.com
Hi
Sent: Wednesday, October 21, 2015 8:21 AM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Stefan Szabo
openvpn server: OpenVPN 2.3.8 x86_64-redhat-linux-gnu
openvpn client: Tunnelblick 3.6beta10 (build 4400)
<connection>
remote 62.231.75.XX
port 80
proto tcp wait 1
</connection>
<connection>
remote 62.231.75.XX
port 1194
proto udp wait 10
</connection>

<connection>
remote NAME
port 80
#proto tcp wait 10
proto tcp .. and other options are not parsed
</connection>
<connection>
remote SAME NAME
port 1194
#proto udp wait 10
proto udp .. and other options are not parsed
</connection>
Wed Oct 21 13:26:39 2015 us=921442 OpenVPN 2.3.8 i486-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Wed Oct 21 13:26:39 2015 us=922386 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
<snip>
Wed Oct 21 13:26:40 2015 us=112379 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:37085 [nonblock]
Wed Oct 21 13:26:50 2015 us=139124 TCP: connect to [AF_INET]xx.xx.xx.xx:80 failed, will try again in 5 seconds: Connection timed out
Wed Oct 21 13:26:50 2015 us=140821 SIGUSR1[soft,init_instance] received, process restarting
Wed Oct 21 13:26:50 2015 us=141197 Restart pause, 5 second(s)
<snip>
Wed Oct 21 13:26:55 2015 us=175752 UDPv4 link remote: [AF_INET]xx.xx.xx.xx:1194
Wed Oct 21 13:26:55 2015 us=196439 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=565ee489 80afc503
<snip>
Wed Oct 21 13:26:55 2015 us=656023 [...] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
Wed Oct 21 13:26:58 2015 us=123524 SENT CONTROL [...]: 'PUSH_REQUEST' (status=1)
Wed Oct 21 13:26:58 2015 us=128551 PUSH: Received control message: 'PUSH_REPLY,{redacted},ifconfig 10.105.101.74 255.255.255.0,peer-id 0'
[Is this a bug .. ?]
Wed Oct 21 13:26:58 2015 us=129086 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:3 is ignored by previous <connection> blocks
Wed Oct 21 13:26:58 2015 us=129494 OPTIONS IMPORT: timers and/or timeouts modified
Wed Oct 21 13:26:58 2015 us=129606 OPTIONS IMPORT: explicit notify parm(s) modified
Wed Oct 21 13:26:58 2015 us=129713 OPTIONS IMPORT: --ifconfig/up options modified
Wed Oct 21 13:26:58 2015 us=129846 OPTIONS IMPORT: route options modified
Wed Oct 21 13:26:58 2015 us=130167 OPTIONS IMPORT: route-related options modified
Wed Oct 21 13:26:58 2015 us=130313 OPTIONS IMPORT: environment modified
Wed Oct 21 13:26:58 2015 us=130418 OPTIONS IMPORT: peer-id set
Wed Oct 21 13:26:58 2015 us=130524 OPTIONS IMPORT: adjusting link_mtu to 1605
Wed Oct 21 13:26:58 2015 us=159018 TUN/TAP device tun86 opened
Wed Oct 21 13:26:58 2015 us=159282 TUN/TAP TX queue length set to 100
Wed Oct 21 13:26:58 2015 us=159502 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Oct 21 13:26:58 2015 us=159707 /sbin/ifconfig tun86 10.105.101.74 netmask 255.255.255.0 mtu 1500 broadcast 10.105.101.255
Wed Oct 21 13:26:58 2015 us=257649 /sbin/route add -net xx.xx.xx.xx netmask 255.255.255.255 gw 172.17.2.1
<snip>
Wed Oct 21 13:26:58 2015 us=411079 Initialization Sequence Completed
Regards

------------------------------------------------------------------------------

[Stefan Szabo]

the only thing that mybe you dont have is that i use ldap module for selecting users who must have acces.

plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so "/etc/openvpn/auth/ldap.conf”

but i dont think this is a problem.

tomorrow i will try a linux client, but as far i tested so far for mac and windows fallback from cfg file is not working.

Post by Stefan Szabo
hi,
without proto tcp declaration it doesnt try over tcp, all that is doing is udp.
if the first line is proto tcp, the first connection is over tcp, after that jumps over UDP.UDP is tried for 5 times after that it resets from the beginning.
the second declaration for remote is not parsed, it only tryes the first one.
i tested both windows7(openvpn gui v4) and mac os(tunnelblick).
Wed Oct 21 16:35:46 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 21 16:35:47 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Oct 21 16:35:47 2015 Attempting to establish TCP connection with [AF_INET]62.231.75.xx:80
Wed Oct 21 16:35:47 2015 MANAGEMENT: >STATE:1445434547,TCP_CONNECT,,,
Wed Oct 21 16:35:47 2015 TCP connection established with [AF_INET]62.231.75.xx:80
Wed Oct 21 16:35:47 2015 TCPv4_CLIENT link local: [undef]
Wed Oct 21 16:35:47 2015 TCPv4_CLIENT link remote: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:35:47 2015 MANAGEMENT: >STATE:1445434547,WAIT,,,
Wed Oct 21 16:36:32 2015 Connection reset, restarting [-1]
Wed Oct 21 16:36:32 2015 SIGUSR1[soft,connection-reset] received, process restarting
Wed Oct 21 16:36:32 2015 MANAGEMENT: >STATE:1445434592,RECONNECTING,connection-reset,,
Wed Oct 21 16:36:32 2015 Restart pause, 5 second(s)
Wed Oct 21 16:36:37 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 21 16:36:37 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Oct 21 16:36:37 2015 TCP/UDP: Preserving recently used remote address: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:36:37 2015 UDPv4 link local (bound): [undef]
Wed Oct 21 16:36:37 2015 UDPv4 link remote: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:36:37 2015 MANAGEMENT: >STATE:1445434597,WAIT,,,
Wed Oct 21 16:36:37 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:36:39 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:36:43 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:36:52 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:37:08 2015 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Wed Oct 21 16:37:37 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Oct 21 16:37:37 2015 TLS Error: TLS handshake failed
Wed Oct 21 16:37:37 2015 SIGUSR1[soft,tls-error] received, process restarting
Wed Oct 21 16:37:37 2015 MANAGEMENT: >STATE:1445434657,RECONNECTING,tls-error,,
Wed Oct 21 16:37:37 2015 Restart pause, 2 second(s)
Wed Oct 21 16:37:39 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 21 16:37:39 2015 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Oct 21 16:37:39 2015 TCP/UDP: Preserving recently used remote address: [AF_INET]62.231.75.xx:80
Wed Oct 21 16:37:39 2015 Attempting to establish TCP connection with [AF_INET]62.231.75.xx:80

Post by d***@gmail.com
Hi
Sent: Wednesday, October 21, 2015 8:21 AM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Stefan Szabo
openvpn server: OpenVPN 2.3.8 x86_64-redhat-linux-gnu
openvpn client: Tunnelblick 3.6beta10 (build 4400)
<connection>
remote 62.231.75.XX
port 80
proto tcp wait 1
</connection>
<connection>
remote 62.231.75.XX
port 1194
proto udp wait 10
</connection>

<connection>
remote NAME
port 80
#proto tcp wait 10
proto tcp .. and other options are not parsed
</connection>
<connection>
remote SAME NAME
port 1194
#proto udp wait 10
proto udp .. and other options are not parsed
</connection>
Wed Oct 21 13:26:39 2015 us=921442 OpenVPN 2.3.8 i486-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 4 2015
Wed Oct 21 13:26:39 2015 us=922386 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
<snip>
Wed Oct 21 13:26:40 2015 us=112379 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:37085 [nonblock]
Wed Oct 21 13:26:50 2015 us=139124 TCP: connect to [AF_INET]xx.xx.xx.xx:80 failed, will try again in 5 seconds: Connection timed out
Wed Oct 21 13:26:50 2015 us=140821 SIGUSR1[soft,init_instance] received, process restarting
Wed Oct 21 13:26:50 2015 us=141197 Restart pause, 5 second(s)
<snip>
Wed Oct 21 13:26:55 2015 us=175752 UDPv4 link remote: [AF_INET]xx.xx.xx.xx:1194
Wed Oct 21 13:26:55 2015 us=196439 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=565ee489 80afc503
<snip>
Wed Oct 21 13:26:55 2015 us=656023 [...] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
Wed Oct 21 13:26:58 2015 us=123524 SENT CONTROL [...]: 'PUSH_REQUEST' (status=1)
Wed Oct 21 13:26:58 2015 us=128551 PUSH: Received control message: 'PUSH_REPLY,{redacted},ifconfig 10.105.101.74 255.255.255.0,peer-id 0'
[Is this a bug .. ?]
Wed Oct 21 13:26:58 2015 us=129086 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:3 is ignored by previous <connection> blocks
Wed Oct 21 13:26:58 2015 us=129494 OPTIONS IMPORT: timers and/or timeouts modified
Wed Oct 21 13:26:58 2015 us=129606 OPTIONS IMPORT: explicit notify parm(s) modified
Wed Oct 21 13:26:58 2015 us=129713 OPTIONS IMPORT: --ifconfig/up options modified
Wed Oct 21 13:26:58 2015 us=129846 OPTIONS IMPORT: route options modified
Wed Oct 21 13:26:58 2015 us=130167 OPTIONS IMPORT: route-related options modified
Wed Oct 21 13:26:58 2015 us=130313 OPTIONS IMPORT: environment modified
Wed Oct 21 13:26:58 2015 us=130418 OPTIONS IMPORT: peer-id set
Wed Oct 21 13:26:58 2015 us=130524 OPTIONS IMPORT: adjusting link_mtu to 1605
Wed Oct 21 13:26:58 2015 us=159018 TUN/TAP device tun86 opened
Wed Oct 21 13:26:58 2015 us=159282 TUN/TAP TX queue length set to 100
Wed Oct 21 13:26:58 2015 us=159502 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Oct 21 13:26:58 2015 us=159707 /sbin/ifconfig tun86 10.105.101.74 netmask 255.255.255.0 mtu 1500 broadcast 10.105.101.255
Wed Oct 21 13:26:58 2015 us=257649 /sbin/route add -net xx.xx.xx.xx netmask 255.255.255.255 gw 172.17.2.1
<snip>
Wed Oct 21 13:26:58 2015 us=411079 Initialization Sequence Completed
Regards

------------------------------------------------------------------------------
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

------------------------------------------------------------------------------

[d***@gmail.com]

----- Original Message -----
From: "Stefan Szabo" <***@rcs-rds.ro>
To: <***@gmail.com>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Wednesday, October 21, 2015 2:46 PM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Stefan Szabo
without proto tcp declaration it doesnt try over tcp, all that is doing is udp.

Post by d***@gmail.com
proto tcp .. and other options are not parsed

I preume by your comment you are confused by this line.

The line is:
proto tcp
No other otions on that line are parsed.

IE: in your case:

proto tcp wait 1

the "wait 1" options are completely ignored by OpenVPN

Regards


------------------------------------------------------------------------------

[Gert Doering]

Hi,

Post by Stefan Szabo
without proto tcp declaration it doesnt try over tcp, all that is doing is udp.
if the first line is proto tcp, the first connection is over tcp, after that jumps over UDP.UDP is tried for 5 times after that it resets from the beginning.
the second declaration for remote is not parsed, it only tryes the first one.
i tested both windows7(openvpn gui v4) and mac os(tunnelblick).

I'm not sure I understand where the issue is now - the log file you've
just sent shows that it tries TCP first, then UDP, then TCP again - that
is what it should do...?

gert

[Selva Nair]

Post by Stefan Szabo
hi,
without proto tcp declaration it doesnt try over tcp, all that is doing is udp.
if the first line is proto tcp, the first connection is over tcp, after
that jumps over UDP.UDP is tried for 5 times after that it resets from the
beginning.
the second declaration for remote is not parsed, it only tryes the first one.
i tested both windows7(openvpn gui v4) and mac os(tunnelblick).

Remove persist-remote-ip and try again

Selva

[Stefan Szabo]

thanks to you all, that line was the problem.

withput it fallback works fine.

Post by Stefan Szabo
hi,
without proto tcp declaration it doesnt try over tcp, all that is doing is udp.
if the first line is proto tcp, the first connection is over tcp, after that jumps over UDP.UDP is tried for 5 times after that it resets from the beginning.
the second declaration for remote is not parsed, it only tryes the first one.
i tested both windows7(openvpn gui v4) and mac os(tunnelblick).
Remove persist-remote-ip and try again
Selva

------------------------------------------------------------------------------

[Selva Nair]

Hi,

<connection>
remote 62.231.75.XX
port 80
proto tcp wait 1
</connection>
<connection>
remote 62.231.75.XX
port 1194
proto udp wait 10
</connection>

This will cause the client to first try 62.231.75.XX:80 tcp and
then 62.231.75.XX:80 udp (not port 1194)
Why? Because of this line in the config:

persist-remote-ip
Your original post had

remote X 1194
remote Y 1194

That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also specified.
This is an unfortunate side-effect of that option.

Selva

[Gert Doering]

hi,

Post by Stefan Szabo
persist-remote-ip

[..]

Post by Stefan Szabo
That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also specified.
This is an unfortunate side-effect of that option.

Ouch.

Could you re-test whether this is still true with git master, please?

(That part of the socked/IP handling got totally rewritten, so "it should
not do that" anymore - but if it does, it's a bug, and should be fixed)

gert

[d***@gmail.com]

----- Original Message -----
From: "Gert Doering" <***@greenie.muc.de>
To: "Selva Nair" <***@gmail.com>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Wednesday, October 21, 2015 7:50 PM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Gert Doering

Post by Stefan Szabo
persist-remote-ip
That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also specified.
This is an unfortunate side-effect of that option.

Ouch.
Could you re-test whether this is still true with git master, please?

I think we may have a problem Houston:

# openvpn --version
OpenVPN 2.3_git [git:master/e8a9e3203bf00605] i686-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [MH] [IPv6] built on Oct 21 2015
library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <***@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no
enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes
enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown
enable_dlopen_self_static=unknown enable_fast_install=yes
enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes
enable_lz4=yes enable_lzo=yes enable_management=yes enable_multi=yes
enable_multihome=yes enable_pam_dlopen=no enable_password_save=no
enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes
enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes
enable_selinux=no enable_server=yes enable_shared=yes
enable_shared_with_static_runtimes=no enable_small=no enable_static=yes
enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no
enable_win32_dll=yes enable_x509_alt_username=no with_aix_soname=aix
with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no
with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

CLIENT CONFIG RELEVANT:

persist-remote-ip

<connection>
remote ME
port 80
# gitmaster spews these errors out correctely
# proto tcp wait 10
# proto tcp .. and other options are not parsed .. are with git
proto tcp
</connection>

<connection>
remote Also ME .. AKA ME2
port 1194
# gitmaster spews these errors out correctely
# proto udp wait 10
# proto udp .. and other options are not parsed .. are with git
proto udp
</connection>

LOG From FULL START not RESTART(watch out):

Wed Oct 21 20:50:51 2015 us=308743 Current Parameter Settings:

<..>

Wed Oct 21 20:50:51 2015 us=328362 OpenVPN 2.3_git
[git:master/e8a9e3203bf00605] i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4]
[EPOLL] [MH] [IPv6] built on Oct 21 2015
Wed Oct 21 20:50:51 2015 us=328589 library versions: OpenSSL 1.0.2d 9 Jul
2015, LZO 2.09

<..>

Wed Oct 21 20:50:52 2015 us=491498 TCP/UDP: Preserving recently used remote
address: [AF_INET]xx.xx.xx.xx:80

<..>

Wed Oct 21 20:50:52 2015 us=491642 Socket Buffers: R=[87380->87380]
S=[16384->16384]
Wed Oct 21 20:50:52 2015 us=491712 Attempting to establish TCP connection
with [AF_INET]xx.xx.xx.xx:80 [nonblock]
Wed Oct 21 20:51:02 2015 us=513757 TCP: connect to [AF_INET]xx.xx.xx.xx:80
failed: Connection timed out
Wed Oct 21 20:51:02 2015 us=514777 SIGUSR1[connection
failed(soft),init_instance] received, process restarting
Wed Oct 21 20:51:02 2015 us=514906 Restart pause, 5 second(s)
Wed Oct 21 20:51:07 2015 us=527643 NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts

<..>

Wed Oct 21 20:51:07 2015 us=530081 Control Channel MTU parms [ L:1602 D:1140
EF:110 EB:0 ET:0 EL:3 ]
Wed Oct 21 20:51:07 2015 us=530175 TCP/UDP: Preserving recently used remote
address: [AF_INET]xx.xx.xx.xx:80

Wed Oct 21 20:51:07 2015 us=537939 TCP/UDP: Preserving recently used remote
address: [AF_INET]xx.xx.xx.xx:80
Wed Oct 21 20:51:07 2015 us=538095 Socket Buffers: R=[87380->87380]
S=[16384->16384]
Wed Oct 21 20:51:07 2015 us=538172 UDP link local: (not bound)
Wed Oct 21 20:51:07 2015 us=538240 UDP link remote: [AF_INET]xx.xx.xx.xx:80
Wed Oct 21 20:51:07 2015 us=538468 write UDP: Broken pipe (code=32)
Wed Oct 21 20:51:07 2015 us=538868 read UDP: Transport endpoint is not
connected (code=107)
Wed Oct 21 20:51:07 2015 us=538974 read UDP: Transport endpoint is not
connected (code=107)
Wed Oct 21 20:51:07 2015 us=539071 read UDP: Transport endpoint is not
connected (code=107)

<18mb of WTF>

Wed Oct 21 20:51:45 2015 us=36828 read UDP: Transport endpoint is not
connected (code=107)
Wed Oct 21 20:51:45 2015 us=36914 read UDP: Transport endpoint is not
connected (code=107)
Wed Oct 21 20:51:45 2015 us=44090 read UDP: Transport endpoint is not
connected (code=107)
Wed Oct 21 20:51:45 2015 us=44306 read UD
Wed Oct 21 20:51:45 2015 us=360253 read UDP: Transport endpoint is not
connected (code=107)
Wed Oct 21 20:51:45 2015 us=378884 TCP/UDP: Closing socket
Wed Oct 21 20:51:45 2015 us=379209 SIGTERM[hard,] received, process exiting


Burn it Link !


------------------------------------------------------------------------------

[Selva Nair]

Hi,

Post by d***@gmail.com
----- Original Message -----

Post by Gert Doering

Post by Stefan Szabo
persist-remote-ip
That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also specified.
This is an unfortunate side-effect of that option.

Ouch.
Could you re-test whether this is still true with git master, please?

If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such seemingly
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP and
port, so why expect something else.

Instead of adding another conditional in the code may I request the
developers to just retire persist-remote-ip or at least ban it when
multiple remotes are specified.

Selva

[Gert Doering]

Hi,

Post by Selva Nair
If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such seemingly
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP and
port, so why expect something else.

If the documentation says so, it's not a bug. Just a weird feature, which
we might want to eventually print a warning about...

Thanks for clarifying. And yes, I do not know all the options yet, some
really pre-date my involvement by a long time.

gert

[Erich Titl]

Hi Folks

sorry to chime in late (and unsolicited)

Post by Gert Doering
Hi,

Post by Selva Nair
If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such seemingly
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP and
port, so why expect something else.

If the documentation says so, it's not a bug. Just a weird feature, which
we might want to eventually print a warning about...

If I recall my network programming in days long ago a net address was
composed of IP _and_ port. Maybe this was the original authors idea.

cheers

ET


------------------------------------------------------------------------------

[Selva Nair]

Hi,

Post by Erich Titl
Hi Folks
sorry to chime in late (and unsolicited)

You are welcome.

Post by Erich Titl

Post by Gert Doering
Hi,

Post by Selva Nair
If I'm not mistaken, persist-remote-ip pre-dates connection-list

support.

Post by Gert Doering

Post by Selva Nair
With multiple options conditionally depending on each other, such

seemingly

Post by Gert Doering

Post by Selva Nair
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP

and

Post by Gert Doering

Post by Selva Nair
port, so why expect something else.

If the documentation says so, it's not a bug. Just a weird feature,

which

Post by Gert Doering
we might want to eventually print a warning about...

If I recall my network programming in days long ago a net address was
composed of IP _and_ port. Maybe this was the original authors idea.

Sure, not having "port" in the option name may be confusing but that is
clarified in the manpage. The implications of it are less obvious to a
casual user.

Programming wise, as you say something like a struct sockaddr_in is what is
persisted.

Cheers,

Selva

[Selva Nair]

Hi,

Post by Selva Nair
Hi,

Post by Selva Nair
If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such

seemingly

Post by Selva Nair
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP

and

Post by Selva Nair
port, so why expect something else.

If the documentation says so, it's not a bug. Just a weird feature, which
we might want to eventually print a warning about...

The manpage says

--persist-remote-ip
Preserve most recently authenticated remote IP address
and port number across SIGUSR1 or
--ping-restart restarts.

Which is not totally correct -- the IP persists even when its not a
previously authenticated one. Even if that is fixed, many users may not
realize all the implications. So, yes, it would be useful to add a warning
to not to use it with multiple remotes or connection lists. The strange
thing is that it will most likely use the same IP even after a SIGHUP
restart or SIGKILL + manual restart, unless the multiple IPs are obtained
by name resolution or random is also specified.

That's why I say its worth considering getting rid of that option.

Selva

[d***@gmail.com]

----- Original Message -----
From: "Selva Nair" <***@gmail.com>
To: "Gert Doering" <***@greenie.muc.de>; "Debbie Tent"
<***@gmail.com>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Wednesday, October 21, 2015 9:37 PM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Selva Nair
Hi,

Post by d***@gmail.com
----- Original Message -----

Post by Gert Doering

Post by Stefan Szabo
persist-remote-ip
That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also specified.
This is an unfortunate side-effect of that option.

Ouch.
Could you re-test whether this is still true with git master, please?

If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such seemingly
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP and
port, so why expect something else.

Gert asked for a specific test, which I tested.
I had no *expectations*



------------------------------------------------------------------------------

[Selva Nair]

Post by d***@gmail.com

Post by Selva Nair

Post by Selva Nair

Post by Gert Doering

Post by Stefan Szabo
persist-remote-ip
That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also >>

specified.

Post by Gert Doering

Post by Stefan Szabo
This is an unfortunate side-effect of that option.

Ouch.
Could you re-test whether this is still true with git master, please?

If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such seemingly
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP and
port, so why expect something else.

Gert asked for a specific test, which I tested.
I had no *expectations*

Easy, that was meant as legalistic remark for an arbitrary user of the
universe.. Nothing personal. In fact if it applies to anyone it should be
the OP who's problem we all were trying to solve..

And, happy to see your test results agrees with mine..

Selva

[d***@gmail.com]

----- Original Message -----
From: "Selva Nair" <***@gmail.com>
To: "Debbie Tent" <***@gmail.com>
Cc: <openvpn-***@lists.sourceforge.net>
Sent: Wednesday, October 21, 2015 10:23 PM
Subject: Re: [Openvpn-users] client config fallback from 1194 udp to 80 tcp

Post by Selva Nair

Post by d***@gmail.com

Post by Selva Nair

Post by Selva Nair

Post by Gert Doering

Post by Stefan Szabo
persist-remote-ip
That will keep trying X:1194 only with whatever protocol is defined before
those lines (or udp by default), if persist-remote-ip is also >>

specified.

Post by Gert Doering

Post by Stefan Szabo
This is an unfortunate side-effect of that option.

Ouch.
Could you re-test whether this is still true with git master, please?

If I'm not mistaken, persist-remote-ip pre-dates connection-list support.
With multiple options conditionally depending on each other, such seemingly
unexpected behaviour is no surprise.. Call it feature or a bug. The user
asked for persist-remote-ip which the manual says will persist both IP and
port, so why expect something else.

Gert asked for a specific test, which I tested.
I had no *expectations*

Easy, that was meant as legalistic remark for an arbitrary user of the
universe.. Nothing personal. In fact if it applies to anyone it should be
the OP who's problem we all were trying to solve..
And, happy to see your test results agrees with mine..

Results you could have SHARED in the FIRST place ..

Happy to see my comments on the OpenVPN "Community"
are *not* unfounded.

/me is Bowing out of this subject -- bored of time wasters

regards


------------------------------------------------------------------------------

[Selva Nair]

Post by d***@gmail.com
Results you could have SHARED in the FIRST place ..

Go through the thread carefully -- I was the first to point out the
conflict between persist-ip and multiple remotes. I tested this with 2.3.8
this morning seeing the OP's post, immediately replied to the list saying
persist-remote-ip is the culprit. That's why Gert asked for a test using
the latest git version. I did not say it was a bug because I still do not
think its a bug -- its an unpleasant feature. I also tested with the git
version and replied to the list in parallel with your report...

Just because I'm being nice to you doesn't mean you have to act like a
dork..

Have a nice day,

Selva

[Selva Nair]

Hi Gert,

Yes the problem remains (see below)..

Post by Selva Nair
hi,

Post by Stefan Szabo
persist-remote-ip

[..]

Post by Stefan Szabo
That will keep trying X:1194 only with whatever protocol is defined

before

Post by Stefan Szabo
those lines (or udp by default), if persist-remote-ip is also specified.
This is an unfortunate side-effect of that option.

Ouch.
Could you re-test whether this is still true with git master, please?
(That part of the socked/IP handling got totally rewritten, so "it should
not do that" anymore - but if it does, it's a bug, and should be fixed)

I never use persist-remote-ip, noticed it only on testing the OP's config.
But it looks like this problem was there for a long time ever since
connection lists were introduced. Surely a weird "feature", if not a bug.

Just tested using git (master/825b3272acb353e0) from github -- github is
refusing connections right now so I'm behind last three commits.. The
problem is still there..

In config:

<connection>
remote myserver 443 <-- myserver resolves to a single ipv4 IP
proto tcp
</connection>
<connection>
remote myserver 1194 <-- same server as above, different port and udp
proto udp
</connection>
persist-remote-ip


TCP port 443 is firewalled, so it should connect to 1194 with udp

Log:

Wed Oct 21 15:57:18 2015 OpenVPN 2.3_git [git:master/825b3272acb353e0]
x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH] [IPv6]
built on Oct 21 2015
Wed Oct 21 15:57:18 2015 library versions: OpenSSL 1.0.1e 11 Feb 2013, LZO
2.06
Wed Oct 21 15:57:18 2015 setsockopt(IPV6_V6ONLY=0)
Wed Oct 21 15:57:18 2015 MANAGEMENT: TCP Socket listening on
[AF_INET6]::1:7500
Wed Oct 21 15:57:18 2015 Control Channel Authentication: using
'keys/xx_ta.key' as a OpenVPN static key file
...

Wed Oct 21 15:57:18 2015 TCP/UDP: Preserving recently used remote address:
[AF_INET]xx.xx.xx.xx:443
Wed Oct 21 15:57:18 2015 Socket Buffers: R=[87380->131072] S=[16384->131072]
Wed Oct 21 15:57:18 2015 Attempting to establish TCP connection with
[AF_INET]xx.xx.xx.xx:443 [nonblock]
Wed Oct 21 15:57:19 2015 TCP connection established with
[AF_INET]xx.xx.xx.xx:443
Wed Oct 21 15:57:19 2015 TCP_CLIENT link local: (not bound)
Wed Oct 21 15:57:19 2015 TCP_CLIENT link remote: [AF_INET]xx.xx.xx.xx:443
Wed Oct 21 15:57:19 2015 Connection reset, restarting [0]
Wed Oct 21 15:57:19 2015 SIGUSR1[soft,connection-reset] received, process
restarting
Wed Oct 21 15:57:19 2015 Restart pause, 5 second(s)

So far so good

Wed Oct 21 15:57:24 2015 Control Channel Authentication: using
'keys/xx_ta.key' as a OpenVPN static key file
Wed Oct 21 15:57:24 2015 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
Wed Oct 21 15:57:24 2015 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
Wed Oct 21 15:57:24 2015 TCP/UDP: Preserving recently used remote address:
[AF_INET]xx.xx.xx.xx:443
Wed Oct 21 15:57:24 2015 TCP/UDP: Preserving recently used remote address:
[AF_INET]xx.xx.xx.xx:443
Wed Oct 21 15:57:24 2015 Socket Buffers: R=[87380->131072] S=[16384->131072]
Wed Oct 21 15:57:24 2015 UDP link local (bound): [AF_INET][undef]:1194
Wed Oct 21 15:57:24 2015 UDP link remote: [AF_INET]xx.xx.xx.xx:443

Its trying UDP next but port stays at 443

Thanks,

Selva