thanks for your response.
Yes, the client side is inaccessible. I tried the "mssfix 576" in
ccd/singapore but to no avail. I have been trying to figure out where
the issue lies from the server logs but cannot find an entry that
indicates "This is Broken Here", even on verbose level 9.
This appears to be where the connection fails, with the two "connection
reset" lines (verb 9)
Oct 30 14:25:20 router01 openvpn: MULTI TCP: multi_tcp_dispatch
Oct 30 14:25:20 router01 openvpn: 184.108.40.206:3817 STREAM: GET
Oct 30 14:25:20 router01 openvpn: 220.127.116.11:3817 Connection
reset, restarting 
Oct 30 14:25:20 router01 openvpn: 18.104.22.168:3817
SIGUSR1[soft,connection-reset] received, client-instance restarting
Oct 30 14:25:20 router01 openvpn: MULTI: multi_close_instance
Kate Kretz wrote:
can you, please, try to add
------------< Log details and configs snipped >---------------
to both ccd/singapore and client config file ?
also I'd recommend to run sniffer (e.g. tcpdump) on both side in order
to see packets
if client side is inaccesible, so add
to ccd/singapore (on the server side)
I agree with you that OpenVPN is mostly mentioned from technical point
of view, just because
it works "out of box" in most cases
On 10/30/07, Drew Gibson <drew@xxxxxxxxx>
I recently sent a router running OpenVPN client (on OpenWRT) to our new
office in Singapore. The router was configured and tested in Toronto,
shipped to Singapore, installed and tested OK. We had a solid OpenVPN
connection back to the Toronto server. Port 1194 is forwarded from our
firewall to the internal OpenVPN server. SSH was disabled on the
router's external interface once the OpenVPN tunnel was up and running.
Our new office (in Singapore) was moved from temporary to more permanent
space, including relocation of the Internet connection and router. The
router is no longer able to establish a full connection with the server
(logs and details below). We are not aware of any changes to the
firewall or server at the Toronto end.
My challenge is that I have no technical resource in Singapore and do
not know enough about OpenVPN internals to infer where the failure lies
from the logs.
I have used OpenVPN for several years at home and in multiple commercial
installations without significant problems. Google searches produced
more pages of source code than real world issues.
Any pointers or assistance in narrowing down the actual issue would be
server log (verb 3):-
Mon Oct 29 14:46:11 2007 MULTI: multi_create_instance called
Mon Oct 29 14:46:11 2007 Re-using SSL/TLS context