Your site is blocked from a region and you don´t know why? Maybe SNI related?

Your site is blocked from a region and you don´t know why? Maybe SNI related?

The other day at work, we received issues from customers. They told us that they couldn´t access to their web Instance. In all the cases, the origin was the same country.

The first thing that I ask, is to give me a screenshot of the error, but it wasn´t a great help.

We also asked for a telnet instance 443

My surprise was that, telnet worked well, but then….

With curl doesn´t work well. Maybe It´s pointing to something related to SSL.

We decided to sniff on the client side, loadbalancer, etc…

We could see RSTs just after the client Client Hello. It indicates that it could be a problem with the handshake, maybe ciphers, etc etc..

Here I don´t have the loadbalancer .pcap files, but as far as I remember, in the loadbalancers we also received RSTs. So what´s sending the RSTs?

Let´s examine the Client Hello inside the .pcap file.

Let´s go down until Server Name Indication extension. After server Name length. It should be the name of the severname (I deleted in this case)

What´s the Server Name Indication Extension: Server Name Indication, often abbreviated SNI, is an extension to TLS that allows multiple hostnames to be served over HTTPS from the same IP address.

Let´s try to change the headers with curl or openssl.

Here you could see how it worked. Why? Let´s go and open the new .pcap file.

In this new .pcap we can´t see the the SNI extension and we can´t also see any of the RST

Ok, if we have more than one site in that ip address it would be a mess, because we would access to the first loaded certificate, but in this case we only wanted to see that the problem was with SNI filtering.

Here you have a nice website to check a website from different agents. In this case agents in China and other regions, to see the differences.

https://www.websitepulse.com/tools/china-firewall-test

SNI filtering is used very often by Internet providers to block access to torrent sites or similar. In this case it might be related to the great firewall (China).

Networking Problem: I can’t connect to your service (tcp) failed: Connection timed out

Networking Problem: I can’t connect to your service (tcp) failed: Connection timed out

Imagine that a friend is trying to connect to one of your services and he mention that when he tries to connect, finally displays a  “(tcp) failed: Connection timed out”

The first thing, I go and check if I could connect to the service, then I’ll check if the service is working properly, if it’s right, I will go and check the firewall…..

Wow, I have all open in iptables, everybody could connect to that service, but I need to deal with my friend and tell him something! Because he told me, that he doesn’t have any rule that could block the connections.

First of all, I’m going to try to simulate this problem.

I open the port listening in X ip.

nc -l 127.0.0.2 3000

 

Then I start sniffing:

tcpdump -vvv -s0 -i lo -w lo.pcap

 

With netcat I also try to connect to the service:

nc -v -z 127.0.0.2 3000
nc: connect to 127.0.0.2 port 3000 (tcp) failed: Connection timed out

 

And now I open the .pcap with wireshark.

127.0.0.1 is my FRIENDS IP and 127.0.0.2 is the service in port 3000.

Here we could see, how my FRIEND/CLIENT send me a SYN, but when I answer with the SYN,ACK the client send me a retransmission of the SYN, and here it’s where the loop starts, because I also have to send him again a SYN,ACK.

The first thing that I think: the origin is blocking the incoming SYN,ACK

 

So I ask my friend for the RULES, and here they are:

 

Wireshark: How to make sure, you are in the right packet!!

Wireshark: How to make sure, you are in the right packet!!

 

Some weeks ago, we had a strange issue: We have an hl7 messaging service, and one of the clients that send us some messages, was telling there´s some delay with our queues. We had to put a sniffer in the client, client firewall, server and 4 firewalls that are in our environment.

The client tells us, that some packets are getting stuck for 3 seconds, and we saw that this packet, was retransmitting. Here we could see the first SYN and the tcp retransmission 3 seconds later.

Sometimes, you don´t have the time synchronized in all the systems, so you will need to make sure which packet you are displaying. Here I will show you the Packet bytes pane of the first SYN and below, the packet bytes from the TCP retransmission:

First SYN – Packet bytes pane. The identification value is 0x4253

TCP Retransmission – Packet bytes pane. The identification´s value: 0x4521

Now I will show you the server side *.pcap, where we only see one of the packets. The first SYN wasn´t reaching the server.

Now we could see on the server side, the IP identification of the packet, that corresponds, with the TCP Retransmission. Value: 0x4521

The problem was in the client´s firewall, but the propose of this message, was trying to identify a TCP retransmission packet, because identifying the packet with the time isn´t a good idea.

Maybe this is too obvious for most of you, but I think it could help for some people.