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.
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?
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)?
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.
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�
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
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.
?
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.
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.
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.
⌠and it seems to have worked with that ⌠
