Xmpp-client

[Francoise Witsell]

HiSupport for ALPN has been added in PR #8913. However, it does not include ALPN types 'xmpp-client' and 'xmpp-server'. It has been requested before and my understanding was that it has also been implemented already. However, upon testing, I came to the conclusion that it does not work yet. Here are all the ALPN protocols including 'xmpp-client' and 'xmpp-server'

I want to use ALPN(xmpp-client) and ALPN(xmpp-server) as to route the correct traffic to the correct container (xmpp server container). As these ALPN protocols are not supported, I can't multiplex on 443 main domain. It has nothing to do with letsencrypt certificate requests. Certificates are manually loaded into traefik and also for the service (xmpp server). As described here and here, the server should set hostsni and ALPN to correctly use xmpp over tls (443).

Works fine directly connected to the isp modem but when behind a WatchGuard (M500 12.7.2) when the thermostat is attempting the xmpp-client/tcp connection to bosch cloud service the first connection succeeds but following connections have a tcp invalid connection state error with the destination as the Firebox rather than bosch ip and this cause the thermostat to fail to communicate with the bosch cloud service.

To remove the possibility that the TCP-UDP-proxy policy is somehow the cause of this, add a Custom Packet Filter for TCP port 5222.

Then add it as a policy, From: 192.168.0.15 To: Any-external

You can turn on Logging on this policy to see packets allowed by it in Traffic Monitor.

Let us know if this helps or not.

Interestingly, this line shows a completed session 9 seconds after the "tcp invalid connection state" for a different session from 192.168.0.15.

The different source ports indicate different sessions.

To me, "tcp invalid connection state" means "Ignore this line!" because I see that all the time on all of my networks and coming from various LAN or VLAN computers, servers, wireless access points, and printers that all are functioning normally. WatchGuard never really has explained why they always fail and why they are trying to hit the Firebox when there is NO policy pointing them at the Firebox.

Thermostat is a Bosch EasyControl, one of the annoying ones that needs an internet connection to work as it used a cloud server to allow remote access via an app on phone and it provides no local connection to enable to manage locally with or without internet.

The https just seems to be the initial check in with bosch as it shows up in the bosch portal, but the functionality of controlling it is 5222 via their cloud server.

The iPhone app to cloud server seems to connect successfully via https pulling in the register thermostat id and does 5222 but then the cloud server can't see the thermostat, this does not suffer from the internal policy issue.

My point is that the "this cause the thermostat to fail to communicate" may be just an assumption and not a log of the actual cause. I get the same "tcp invalid connection state" errors when devices work perfectly, so it may be a spurious message that actually has nothing to do with the cause of the failure.

Regarding "Even tried a top level Any packet filter From: 192.168.0.15 To: Any-external", I assume that you mean that rule was manually moved above all other policies vs. using auto-ordering of policies. Is that correct?

Speaking of NAT, when you say, "Works fine directly connected to the isp modem", is the modem doing NAT, i.e., you have a dual-NAT setup here where the ISP has a private IP on the inside of its modem and the WatchGuard is on that private network as its WAN side? Or does the WatchGuard have a public IP on its WAN?

As an example of why I ignore those messages, the wireless AP at 192.168.16.212 has zero issues communicating with its controller at 10.0.6.101, yet the logs are full of the tcp connection state "error" messages.

3a8082e126