Something is blocking connections between interfaces

Installing and Using OpenWrt Network and Wireless Configuration
1

I have a Xiaomi MiWifi Mini running LEDE 17.0.1.4, and behind it I have two servers (Raspberry Pis) and my PC.

The PC and the servers are all connected to the router with Ethernet cables, but since the MiWifi Mini only has two lan ports (and one wan), I have added another lan port to the router with a USB to Ethernet adapter.

The native ports are listed as eth0.1 while the USB<->Ethernet port is listed as eth1, and I have added eth1 to the bridged lan. Server1 is connected to one of the native ports and server2 to the adapter port, while my PC is connected to the remaining native port.

I have had no problems with this setup, until I tried to establish an SSL connection from Server1 (native port) to Server2 (adapter port). SSL handshake negotiation with:

username@hostname:~ $ curl -vv https://192.168.X.XX
* Rebuilt URL to: https://192.168.X.XX/
*   Trying 192.168.X.XX...
* TCP_NODELAY set
* Connected to 192.168.X.XX (192.168.X.XX) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to 192.168.X.XX:443 
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to 192.168.X.XX:443

I have no problems with SSL negotiation from PC > Server1/2, LEDE > Server 1/2, Server 2 > Server 1 or WAN > Server1/2/LEDE.

Only Server 1 > Server 2 fails.

I don't see anything in the NginX error logs on either server. I have ruled out firewall issues on the servers (by disabling them), but UFW did show and [AUDIT], when it was installed. Now I have clean installed sever2 without UFW, but the connection is still dropped.

Netdata on server1 does show a lot of dropped connections on eth0, when I attempt the SSL handshake, and I found out, that server2 tries a lot of connections to server1 from and to various ports (none of them are 443 though).

Is there an iptables wizzard around, that can help me troubleshoot? Thanks in advance :slight_smile:

2

At first sight, this does not look to me that this is related to the router at all...

1 Like
3

Thanks for your reply.

You are probably right, but I do not know what else could be blocking it. Do you have an idea where else to look?

I do not understand why handshake negotiation succeeds on all but this particular host, when the Raspberry Pis are running practically identical software.

4

My first bet would be that the client on one host is not compatible with the server on the other host. To rule out network issues, I would try to connect both hosts using as little hardware as possible: a direct cable, or a dumb switch, for example.

5

Thanks for your reply!

If I ssh into the router I can successfully complete ssl handshake with both servers, and the same goes for my laptop, that is also cabled to the router and has a DHCP assigned ip.

I am pretty sure the USB/Ethernet adapter introduces the problem though, because I just switched the ethernet cables for the servers, so server2 is connected directly to the router in eth0.1 and server2 is connected to eth1 in the adapter.

Now ssl handshake negotiation succeeds from server1 to server2, but fails from server2 to server1 (so the opposite of my original problem).

Netdata shows me that connections are dropped at the interface level, when handshake negotiation is running.

It was more important for me to be able to do ssl connections from server1 to server2 so switching the cables partially solved my problem, but I would still like to find out what is blocking the connection :slight_smile:

6

Is this something to do with Vlan tags? Seems unlikely.

Wireshark might help here

7

@moretocome,

Wireshark is an excellent suggestion by @dlakelan.

You can learn about it and download it here...

https://www.wireshark.org/

8

Thanks for the tip @dlakelan and @jwoods.

Yes I tried poking around a bit with tcpdump and Wireshark, but it is my first time trying out both pieces of software, so I will have to read a guide to do it properly some time.

Until now I have postponed the problem by switching the lan cables for the servers :blush:

Thanks for the help guys!