On 11 Jul 2011 at 20:59, Paul Suh wrote: > On Jul 11, 2011, at 5:57 PM, Jacob L. Leifman wrote: > > > Environment: > > - OpenBSD 4.9, stock (base) apache with self-signed certificate > > - behind a SOHO NAT router (with relevant in-bound redirects) > > > > Problem: non-local SSL connections never complete the handshake > > (verified while monitoring the interface with tcpdump, see below) > > > > During troubleshooting I was able to eliminate a few suspects: > > - Regular un-encrypted HTTP (port 80) works every time; > > - https:// from the same LAN (i.e. no NAT) always works; > > - SSH always works (whether local or remote); > > - PF seems to have no bearing -- no difference in behavior whether > > enabled, enabled with "pass in quick" for the remote test host, or even > > altogether disabled. > > > > Unfortunately, I cannot eliminate the NAT device and need to find a way > > to work with it. > > *snip* > > Jacob, > > A few things to try: > > 1) Try a non-OpenBSD server on the inside, just to see if the problem is > specific to OpenBSD or occurs with other server types.
good idea. I will try it as soon as I can which will not be for a few days. > 2) Try using > > openssl s_client -connect hostname:443 > > from the outside and see what kind of error message you get back. did that (as well as lynx and some others) -- there are no error message, just times out. > 3) Try connecting from the outside using wget or curl and see what kind of > error message you get back. see just above. > FWIW, I'm guessing that the problem is at the router. The packet trace is > showing a TCP SYN coming from the client, followed correctly by a SYN-ACK > going back from the server. The client should send an ACK packet back, but > instead it waits several seconds (i.e., timeout) then sends another TCP SYN, > which would be what happens when the client does not receive the SYN-ACK from > the server. Can you get a packet trace from the outside interface of the > router? I believe you are right; or at the very least it is some kind of weird interaction with the router. Unfortunately, this is a consumer DSL device with no packet capture/trace capability. > Hope this helps. some more leads to chase ;-) > --Paul > > [demime 1.01d removed an attachment of type application/pkcs7-signature which > had a name of smime.p7s]
