loic02
Hello,
I am using a virtual Untangle box in tcp mode on port 1194.
I keep getting disconnected after 1mn~, then have to wait 10s before having connection again during 1mn etc etc...
The line is fine because there was another server running openvpn before which has been replaced by Untangle.
Everything was working fine with the old server.
Server conf :
proto tcp-server
mode server
ca data/ca.crt
cert data/server.crt
key data/server.crt
dh data/dh.perm
client-config-dir ccd
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
ccd-exclusive
tls-server
#tun-mtu1500
mssfix
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4
mute 20
management 127.0.0.1 1195
port 1194
dev tun0
ifconfig 10.1.15.1 10.1.5.2
push "route 10.1.5.1"
route 10.1.5.0 255.255.255.0
push "route 20.1.1.0 255.255.255.0"
max-clients 500
Client conf :
#AUTOGENERATED BY UNTANGLE DO NOT MODIFY
# OpenVPN(v2.0) configuration script
client
proto tcp
resolv-retry infinite
#tun-mtu 1500
keepalive 10 120
#ping 0
#ping-restart 0
cipher AES-256-CBC
nobind
mute-replay-warnings
ns-cert-type server
comp-lzo
verb 4
persist-key
persist-tun
tls-exit
dev tun0
cert untangle-vpn/X.crt
key untangle-vpn/X.key
ca untangle-vpn/X.crt
remote X 1194
Server log :
If needed?
Client log :
Fri Jun 29 15:33:41 2012 us=578000 Preserving previous TUN/TAP instance: Local Area Connection 3
Fri Jun 29 15:33:41 2012 us=578000 Initialization Sequence Completed
Fri Jun 29 15:34:37 2012 us=375000 Connection reset, restarting [0]
Fri Jun 29 15:34:37 2012 us=375000 TCP/UDP: Closing socket
Fri Jun 29 15:34:37 2012 us=375000 SIGUSR1[soft,connection-reset] received, process restarting
Fri Jun 29 15:34:37 2012 us=375000 Restart pause, 5 second(s)
Fri Jun 29 15:34:42 2012 us=375000 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Jun 29 15:34:42 2012 us=375000 Re-using SSL/TLS context
Fri Jun 29 15:34:42 2012 us=375000 LZO compression initialized
Fri Jun 29 15:34:42 2012 us=375000 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Fri Jun 29 15:34:42 2012 us=375000 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Jun 29 15:34:42 2012 us=375000 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Jun 29 15:34:42 2012 us=375000 Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Fri Jun 29 15:34:42 2012 us=375000 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Fri Jun 29 15:34:42 2012 us=375000 Local Options hash (VER=V4): '958c5492'
Fri Jun 29 15:34:42 2012 us=375000 Expected Remote Options hash (VER=V4): '79ef4284'
Fri Jun 29 15:34:42 2012 us=375000 Attempting to establish TCP connection with X:1194
Fri Jun 29 15:34:42 2012 us=390000 TCP connection established with X:1194
Fri Jun 29 15:34:42 2012 us=390000 TCPv4_CLIENT link local: [undef]
Fri Jun 29 15:34:42 2012 us=390000 TCPv4_CLIENT link remote: X:1194
Fri Jun 29 15:34:42 2012 us=406000 TLS: Initial packet from X:1194, sid=c505a620 1446cb58
Fri Jun 29 15:34:43 2012 us=15000 VERIFY OK: depth=1, /CN=ca.does.not.exists/C=BE/ST=Namur/L=Namur/O=XXX
Fri Jun 29 15:34:43 2012 us=15000 VERIFY OK: nsCertType=SERVER
Fri Jun 29 15:34:43 2012 us=15000 VERIFY OK: depth=0, /C=BE/ST=Namur/O=XXX
Fri Jun 29 15:34:45 2012 us=78000 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jun 29 15:34:45 2012 us=78000 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jun 29 15:34:45 2012 us=78000 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jun 29 15:34:45 2012 us=78000 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jun 29 15:34:45 2012 us=78000 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1536 bit RSA
Fri Jun 29 15:34:45 2012 us=78000 [server.does.not.exists] Peer Connection Initiated with X:1194
Fri Jun 29 15:34:47 2012 us=171000 SENT CONTROL [server.does.not.exists]: 'PUSH_REQUEST' (status=1)
Fri Jun 29 15:34:47 2012 us=453000 PUSH: Received control message: 'PUSH_REPLY,route 20.1.1.0 255.255.255.0,route 10.1.5.1,topology net30,ifconfig 10.1.5.6 10.1.5.5'
Fri Jun 29 15:34:47 2012 us=453000 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jun 29 15:34:47 2012 us=453000 OPTIONS IMPORT: route options modified
Fri Jun 29 15:34:47 2012 us=453000 Preserving previous TUN/TAP instance: Local Area Connection 3
Fri Jun 29 15:34:47 2012 us=453000 Initialization Sequence Completed
I spent 3 days working on this issue, I really need some help 🙁
Everything works fine if I switch to udp! But as I have to pass through a proxy I need to use it in tcp...
Thanks,
Loïc
maikcat
hi there,
did you posted to the untangle forums?
which version are you using? 9.2?
keep in mind that untangle also has many other apps (intrusion detection etc)
that filters traffic...
also the big problem is that configs are re-created every time you reboot the appliance..
i suggest you post first to their forum (its very active).
Michael.
maikcat
after you client is connected your logs show "closing tun/tap interface"
something tries to shut down the interface..? :?
also openvpn proccess receives sigterm...thats not good..
i read the post on untangle forums,
i am puzzled about dmorris response...he owns untangle.
btw ,what exactly did you do to "hack" it?
Michael.
loic02
Biggest hack ever :
I changed "proto udp" with "proto tcp-server" in the server.conf file in Untangle and restart openvpn service.
I used the word "hack" because I already read it on untangle forums regarding the use of tcp.
Anyway I am wondering if they know what's going on inside their own appliance. There must be something interfering with openvpn but no one seems able to *willingly* answer that...
Can you do something for me regarding the logs?
I appreciate your help ! (not a sarcasm on this forum 😛 )
Mimiko
loic02, the only options (udp or tcp) is that which work best in your case. Statistically, udp configuration is preferable, other tcp.
