Skip to content
Archive of posts filed under the TCP/IP category.

OpenSSL s_client recipes

This post is pretty much a reminder note to myself how to quickly start debugging certificate errors. I have googled this stuff way too often.

Checking the certification expiration date:

openssl s_client -connect | openssl x509 -text

You could also add -servername parameter to support new ssl spec

 openssl s_client -servername -connect | openssl x509 -text 

Then see these blocks

Not Before: Mar 22 00:00:00 2016 GMT
Not After : Mar 23 23:59:59 2017 GMT

Let’s verify the whole certificate chain:

openssl s_client -showcerts -connect

This is the most common case for me. Most of the time the certificate is somehow installed in a wrong way. One common error is that the certificates are sent to the client in wrong order. This is fine for most of the clients, but at least Android seems to be expecting correct certificate order, as specified in the RFC document.

After this we can make simple GET request to the host with

GET /myresource.html HTTP/1.1

After this remember to press the enter twice.

Playing with Boundary’s Application Monitors

Boundary offered free Rasberry Pis for testing their Application Monitors.

The Boudanry’s service provides monitors for network traffic. It’s really handy service, if you have a big service with  10+ servers at production, and you’re wondering where the bottlenecks are. Then the monitoring service could save you a lot of trouble. You can instantly see that “Machine X” has big latency, so it hast to be the bottleneck for the service, and it should be fixed. I really like statistics, so I might still continue using these with some of my servers, even while I don’t have that much network traffic.

Boundary Application Monitors

Boundary’s Application Monitors

I had an Ubuntu Server installation on VirtualBox, so I thought that cloning the image would be an easy way to get free Rasberry Pi, and it was ;-)  Just right-click on the server installation, and click “Clone”, and then choose “Linked Clone” in the cloning configuration.

cloning in virtual box

cloning in virtual box

Continue reading ‘Playing with Boundary’s Application Monitors’ »

Creating a SOCKS5 proxy for Diablo III

Here’s a simple tutorial how to create SSH Tunnel and Socks proxy to play Diablo III behind a firewall, or just to avoid 3007 errors. You’ll only need a SSH server where you can connect to.

Creating the SOCKS5  SSH tunnel with Putty

Step 1: Open Putty and go to the Tunnels menu. Set source port to 9999, and then set Dynamic as the port type, and press Add.

Set the Tunnel port into 9999, set port type to dynamic, and press add

Step 2: To prevent unwanted disconnects from the SSH server you should set a value to “seconds between keepalive packages”. Open the Connections menu and set some value to seconds between the keepalive packages. 30 seconds is smaller than my server’s disconnect time, so that’s fine for me.

Set the seconds between keepalive packages to 30

Step 3: Open the session page, and connect to SSH Server. Just replace the Host Name “” with the server you want to connect to.

You can also save your session in this page (if you don’t want to configure the SSH tunnel again) by writing a name into the saved session, and then pressing save.

Write your server address to the host name and press Open

Write your server address to the host name and press Open

Choosing the Proxifier Software

The Proxifier is a proxy server, that can route your traffic though the SOCKS SSH tunnel, that we just created. The Diablo III uses UPD, so you should choose Proxifier SW that supports the SOCKS5 UDP Associate. You can get pretty good comparison at Wikipedia article here: I decided to use Widecap, since it’s for windows, it supports UDP, and it’s free.

Continue reading ‘Creating a SOCKS5 proxy for Diablo III’ »

Solving the 3007 error in Diablo III

I had pretty much same problem that’s described in this forum post: Most of the 3007 error pages are just full of trolling, but this one seems quite informative, so I keep that as a reference.

At fist I started the WireShark to see what’s going on. The log was full of TCP Retransmission packets telling me that the TCP packest aren’t going though. My best guess is that my ISP is marking those packets as bittorrent packages, and then the QOS is heavily limiten their bandwidth.

I filtered the dns records, and I noticed that in the login phase the Diablo III is connecting into port 1119, and that my network traffic into that IP is quite limited. My first ideas was to create SSH tunnel, and tunnel the port 1119 into the battlenet.

Creating the SSH tunnel

I added the line to the windows host file, to route all traffic to into my localhost.

After this I opened putty, and set the Tunnel in the Putty’s tunnels menu. I created a local tunnel into port 1119(that’s where I’ll be getting the packages from diablo III), and then I set the destination into (where all that data should go).

Did it work?

Well, it didn’t work. After going though the Wireshark logs I noticed that there are some other ports (seemed like random) opened into too, and there was some UPD packages as well, so regular SSH tunneling wasn’t enough.

However in this kinds of situations we can use the SOCKS5 Proxy to tunnel though a single SSH tunnel into the

Creating a SOCKS5 Proxy for Diablo

SOCKS5 to the rescue. I used putty to create the SOCKS tunnel in the Putty’s tunnel menu by biding a local port 9999, and choosing the tunnel type as dynamic. Then I used Widecap as a proxyfier to make a proxy for Diablo III. I proxied only the IP for the, since I didn’t wan to was any more bandwidth from my SSH server than I had to. I also blogged about SOCKS5 for Diablo III in more details at