Help diagnosing some kind of connection drops

This is not entirely related to IPFire, but since the connection goes through IPFire, well, may it is related after all. I am not sure.

Trying to figure out what could cause issues with the connection from 192.168.1.12 to 192.168.10.10.

On 192.168.1.12 (lower section in the server square) I have a monitoring app, UISP by Ubiquiti. It is a server made by them to monitor their devices, usually in much larger environments. It works rather well and can handle firmware updates, uptime and downtime notices for all my devices on the network, a bit like WIO can for IPFire.

It requires an UI Router connected to the network to work. That is in place at 192.168.1.6, it serves no other purpose but to be some kind of passive gateway for UISP.

I attach an updated diagram.

So for some reason it connects initially with the EdgeSwitch and with the AP’s connected to that, but drops and is not consistent, either by dropping or reconnecting.

IPFire is the Firewall+Router at the top. Cabling is correctly drawn.

What can I do or what should I look for in IPFire to see what is going on with these connection drops?

1 Like

Ok, found something…

192.168.10.10 is the PoE switch that handles my AP, what is it dropping?

found some more

1 Like

The topic title reports “connection drops”.
Would you please describe what actually happens in these (supposed) connection drops? The simplest (not shortest) way possible of what happen.

Is UISP by ubiquiti designed for being trans-subnet (and without a Ubiquiti device as gateway)?

Do you have a firewall rule to allow the POE switch on blue to talk to the UISP server on green?

1 Like

I do not fully understand that. The Edge6P is in place to act as gateway for the UISP and it accepts it. All green in the UISP interface. The device adoption ( a connectivity thing by UISP) works, but after that it drops.

Looks like this. All items have been successfully adopted by UISP,b but the grey ones are disconnected at that time.

No. Since the devices were initially adopted by the UISP I could initially establish that the connection via IPFire was viable. Had it not been the case, full stop = no connection, then I would have considered a firewall rule. As it is I do not know what is causing the problem, since it is not ON or OFF but somewhere in between.

From the logs it looks like the POE Switch is trying to forward packets to the UISP, not as part of an existing connection and so you are getting a DROP_Wirelessforward message.

If all communication is supposed to be only triggered by the UISP to make a connection that the POE can respond to then you need to find out why the POE Switch is trying to connect to the UISP on its own.

2 Likes

see the Trouble note at the bottom of this wiki page:

https://wiki.ipfire.org/configuration/firewall/accesstoblue#trouble


PS - Thank you for the network drawing - This is one of the best ones I have seen!!
:star: :star: :star: :star: :star:

I wish everyone would do this - it makes it so easy to help!

4 Likes

PS. I did post a thread about that and how to learn to do them. Network diagrams - post and comment and learn (?) . It did not really evolve, which I still find a bit strange. I am very grateful for your kind words.

The communication should be two-way. UISP send pings to check for uptime, checks firmware version, and some other stuff. The Switch and AP sends back response and additional info.

I do have a pinhole rule, those devices are not in it. Because they are not using Wifi to connect.

Lets see… thinking out loud here, please excuse the shouting…
so if a wired device is part of the BLUE Network, despite being wired, but having an IP from the BLUE IP Range, it is considered part of the BLUE network despite not being wireless. So adding the 192.168.10.10 switch, and the 192.168.10.2 AP to the devices listed in my pinhole should sort that… ?

Even the two way communication part to the 192.168.1.12 server on port 40443 ? And also allowing the EdgeRouter acting as gateway for UISP on 192.168.1.6 in there as well…?

Is it here I call out EUREKA?

1 Like

Yes!

the BLUE network is normally used for Wireless (Wi-Fi). In your case (and in my case) it is used for wired (ethernet) devices. And this is perfectly fine!

So for your wired devices (via ethernet) you’ll need to do follow the Blue Access items

5 Likes

Actions taken.

Added all affected devices to BLUE Access table.

  • UISP server at 192.168.1.12 (two way comm with all UI devices)
  • EdgeSwitch 5XP at 192.168.10.10 (where my AP’s are, and will be, connected)
  • EdgeRouter6P at 192.168.1.6 (the useless but necessary UISP Gateway device)
  • AircubeAC ( 1 AP, which actually was already connected)

A bit tricky, one has to get the correct MAC from devices with multiple MACs /NIC port’s. The UISP is also a Virtual Machine and I am not sure that Mac is really static. Will have to check that setting in Hyper-V.

For now they are not in the pinhole. I did above first see how that works, if no or limited results, I will add them to the pinhole.

:white_check_mark: … and it seems to have worked with that … :zap: :tada:

image

I cannot tell if this was successful or not. The added image throws me off…

1 Like

It is intended to be ambiguous … :blush:

1 Like

hum, and after the upgrade to 182 it stopped working.

I will try removing and re adding them to Blue… if not, well, I can still try adding them to pinhole .

I do not see anything related to that in the release notes, but I only understand half of what it says anyways…

https://www.ipfire.org/blog/ipfire-2-27-core-update-182-released

?
Do you have a firewall rule to allow Ubiquity devices in Blue zone to talk to UISP device in green. Not sure of ports required. Would need to check.
Create USIP group and a USIP service group.

Trying to do that.

One device turns up as deleted seconds after I added it to the group.

image

How am I going to add all those ports specified in the UI doc?

Making a new service and adding multiple protocol and ports to it?
image

The host name is different in the two locations.

‘’‘’‘UI EdgeSwitch5XP’‘’’

vs

‘’‘‘UI EdgeSwitch 5XP’’‘’

There is an extra space in the second host name.

Ah, I see. Thanks.

I guess I have to remake the group.

Ok, that fixed. I think I may have confused the name with the remark.

Glad it got resolved for you.

I need to have a look at the code as it should flag up that you have created a host with the same ip/mac as an existing name.
It also shouldn’t allow you to modify the name to a different one if the host is already used in a group somewhere.

1 Like

Yes.
Add each service port
Then lump them into a service group.

You could add the hosts to a network group.
And allow all. Atleast as a test.

So I kinda forgot about this and never implemented the service group, but after updating to 183 suddenly the devices with drops are talking to each other again.

Before the update to 183
image

…and now that error is gone.

Me no comprende.