Doesn't seem like it is a very common choice in hardware so there are astonishingly few posts about configuration. I'm finding things as trivial as port forwarding to be absurdly hard to get working.

-Alex

For the past several weeks we have been blessed with fantastic weather. Clear Skies for days.

We have also seen that one of our pTp links (about 400') with a nanobeam 5AC Gen2 at one end goes down. I re-power the nanobeam and the link comes back up within minutes. This happens when the sun shines almost directly on the face of the nanobeam.

What can I do to know more/troubleshoot?

TIA

• Turn on ssh and from the console session you can run vtysh. This will give you a wealth of diagnostics that are not available from the web GUI. Consult the FRR manuals for details.

• Download the config after you upload, or use 'show run' from a vtysh session to see what parts of your config were accepted. Some commands for FRR are not supported and will be ignored.

• Order matters in the config file. 'ip prefix-list' and 'route-map' are two examples of lines that must come after the 'router bgp xxxx' section or they will be ignored.

• 'ip route x.x.x.x/x Null0' does not appear to be supported. To advertise a subnet, it must be active in the routing table by some other means.

This information was current as of v5.4.1. Best of luck!

Topology: Ethernet generator / airFiber 5XHD <-> UISP-S-Plus port 7--port 5 <-> UISP-S-Pro te1--gi15 <-> Ethernet generator / airMAX AC AP.

Plus ports 5/7: trunk, no native VLAN, jumbo enabled, outer VIDs 20/110 explicitly tagged/allowed. Pro te1/gi15: trunk, native VID 4095, outer VIDs 20/110 explicitly tagged/allowed. No TPID conversion was introduced. Management and unrelated customer VLAN details are omitted.

Each batch contains eight marked synthetic ARP frames for each stack: [20], [110], [20,3982], [110,3982]. Both TPIDs are 0x8100. Every original frame is 100 bytes excluding FCS. The inner diagnostic VID 3982 is not provisioned for intermediate switching: transparent customer-tag preservation is the requested behavior. Markers identify test, phase, kind and sequence; comparison is byte-exact.

Measured results:

1. Pro gi15 RX SPAN calibration: 32/32 frames exactly match the sender, including all 16 double-tag frames.

2. Direct Plus port 7 RX SPAN: all 16 double-tag frames have exact counterparts with both tags intact. This file also retains a few normal-forwarding duplicates, explicitly documented.

3. Cable after Plus / before Pro: all 16 double-tag frames lose precisely the inner four bytes; the 16 single-tag controls remain unchanged.

4. Reverse path: Pro te1 TX SPAN preserves all 16 double-tag frames, but Ethernet reception at the airFiber after Plus shows the same frames with the inner tag removed. Every remaining byte matches.

Example (no FCS):

Before: DST SRC 8100 006e 8100 0f8e 0806 [ARP + padding] = 100 bytes

After: DST SRC 8100 006e 0806 [identical remaining bytes] = 96 bytes

Measurement caveat: Plus TX SPAN itself omits the outer tag even for single-tag controls. The actual Ethernet receiver retains it. An untagged TX SPAN copy therefore does NOT prove an untagged wire frame. The localization combines direct ingress, the calibrated Pro SPAN and actual receiver captures.

These small frames rule out a jumbo-size ceiling as the explanation for the exact four-byte transformation. Tests characterize one Plus unit and its tested port pair. We have NOT tested outer 0x88a8, another firmware, another Plus unit, other inner VIDs, unicast or full-sized traffic. Some phases were sequential, not simultaneous passive taps.

For Ubiquiti engineering: is transparent 0x8100/0x8100 transit supported on UISP-S-Plus 1.11.1? Is there a supported preserve-inner-tag/provider-NNI setting or firmware fix? Does 0x88a8/0x8100 coexist with ordinary single-tag 0x8100 services? Is selective outer-VID TPID translation supported? The model-specific public catalog currently lists 1.11.1 as latest; we found no published QinQ fix.

The attached sanitized package contains 12 PCAPs, complete frame-hex CSV, SHA256 manifest, offline Python validator, full English technical report and Spanish summary. Only marked synthetic ARP probes are exported. Ethernet/ARP MACs are consistently anonymized; timestamps independently normalized per PCAP. Tag values/order, lengths, markers and other bytes remain intact. Original captures are retained privately. No production IPs, company/site names, credentials, serials, controller addresses or configuration dumps are included.

All temporary mirrors/ACLs were removed and baseline configurations restored. One direct-mirror trial needed recovery of a Plus port stuck in Learning after mirror removal; STP was temporarily disabled/re-enabled on that port and restored. The subsequent trial incorporated recovery and rolled back automatically. The full report documents this separately.

We welcome a supported configuration or engineering reproduction. Current IP Ethernet tunnels are an operational workaround, not the desired native-QinQ solution.

Attachments:

• UISP-S-Plus-QinQ-Evidence.zip

Example of a webserver:

Now the wireguard uses :

You would think that would be the same rules but then a different subnet, and then the BIG question what interface ?

I tried bridge, that does not work

It has 8 2.5Gbps PASSIVE POE ports (passive POE not available on stock Xyzel FW), and 2 SPF+ cages. Here's the dashboard:

I took some inspiration from familiar switches and manufacturers that we've all worked with.

This switch is powered by a Meanwell LAD360D - a 360W 54V PSU, UPS, and battery charger. A great device. We wire 4 12V SLA batteries in series for battery backup. We install these switches on residential rooftops, and the power goes in a Hana Wireless fiberglass box on the side of the home.

We run a 12 gauge UV rated SJ line up to the roof where the switch lives. The switch is in a Ubiquiti Flex Pro box. We drill two holes in the back of the box for fans.

The fans are powered by POE out on a configurable port, and they are triggered by the switch's own temp reading. You can configure what temperature triggers the fans, and what temp turns them off. We use a tiny mikrotik POE splitter and made the fan port the customer access port for the home owner. Home owner gets 2.5Gbps capacity and the port serves a dual function and also powers the fans. One intake and one outtake fan. 2.5G POE switches running hot isn't an excuse to not make a product because there is always a solution to every problem! You can see the fans doing their job here:

You can also see the heater and Siklu snow melter - the heater kicks on like the fan, forced POE out. I don't anticipate needing it because the POE output will keep the switch warm enough I think - it runs pretty warm as most 2.5G POE switches do. The Siklu snow melter is a pretty slick one and is a feature mainly for our area (we are in Utah ❄️). You put the switch's GPS coords into the setting card, and when there is forecasted snow (the switch is connected to weather.gov) it will turn POE on automatically to keep your backhaul dishes clean from snow.

The switch will tell you the immediate neighbor IP, MAC, name, make and model, and firmware version using LLDP data. I'm shocked no other switch does this (at least none that I know of).

My favorite feature is how it handles power outages. When the power goes out, the switch pulls battery off the PSU, and there is a voltage drop. The switch sees this and will send an email to you letting you know that power is out, and will provide an estimated battery runtime based on the battery capacity data that you enter into the switch. Once a power outage commences, the switch will refresh and check the MAC table of each AP port. If there are no MACs present (like if there is an area wide power outage and all the CPEs on an AP are offline) the switch will drop power on that AP's port to boost battery runtime for APs that still have customers connected. Once AC is restored, it turns the ports that it killed back on. All of this happens automatically with 0 human intervention. It handles power outages like a dream.

Other neat stuff like:

- 200+ watts of POE budget (documentation for the device states 130w but I learned that is only because the PSU that ships in box with the switch is only capable of 130W, and the switch itself is capable of more)

- 60w per port (it has powered a Siklu 8010FX)

- Desktop AND Mobile optimized UI - logging into a UISP switch on your phone browser kinda sucks

- port isolation

- LAGs (with working port isolation - for some reason UI switches don't allow port iso on LAGs)

- flexible VLAN configuration

- Watchdog

- it will email you letting you know it's time to replace the batteries once they are 4 years old

- POE Forced on (passive) or POE Auto (at)

- Keeps the last hours worth of traffic data for troubleshooting

Here is in action:

A quirk - this is a hardware issue that Claude can't solve. There is a pretty serious ground isolation issue where if the radios are using shielded cables, there will be ground loops and all sorts of weird power issues will present themselves. For example, radios will stay powered even when POE is turned off on the port, because power is making it out the ground. To solve this problem, we use plastic ends on the switch side, and ground all the CAT5 drain wires to a bus bar in the box to keep the ground from passing through the switch. The radios and the switch are grounded independently. Slight inconvenience, but problem solved.

This post is not an attempt to sell a firmware image for a 3rd party switch (legally not for sale, but I'm happy to share the .bin with anyone interested in trying it) - it is an attempt to wake UI the freak up. Using AI, this firmware was made in less than 2 months for existing hardware - the S16 is 11 years old! That's insane. Please remove WISPs from the back burner! There is no excuse now that AI has made it possible for a simpleton like me to create something cool like this. I sincerely hope UI will not forget their roots and start showing WISPs some love! It is maddening watching Unifi get a new product every other week- UISP sales would absolutely pick up if WISPs were treated the same, this is a fact. It feels like UI is acting like the golden age of WISPs is over, but that is just not true. We operate in an area with extremely dense competition - municipal fiber, the big evil cable company, big fiber, and of course Starlink - and we're still growing like crazy with Wave and excellent customer service. @UI-Team WISPs aren't nearly as obsolete as you seem to believe!

Thank you for your time 🙏

Either way we updated them to 1.12.2 and we are seeing other issues at this point. 2 days after the reboot one of our switches decided to turn off POE for a few hours and then turned it back on. We have never seen this issue before but now I'm thinking we need to roll everything back again because we cant have equipment just turning off for no reason.

I have self-hosted UISP server based on docker nico640/docker-unms

With UISP i have connected

• 1 edge router x
• 2 edge router x sfp (erx-sfp-1, erx-sfp-2)
• 2 nanostation loco m2 (loco-m2-1, loco-m2-2)

The loco-m2-1 is connected and powered with Poe to erx-sfp-1.

The 2 loco-m2 stations cannot get connection to uisp due to this error

The problem could be the bolded row below

Aug 16 08:59:48 udapi-bridge[1522]: unms: connecting to 57.131.24.77:443

Aug 16 08:59:48 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-status, id: fake

Aug 16 08:59:48 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-startPing, id: fake

Aug 16 08:59:48 udapi-bridge[1522]: unms rx: name=unms-status socket=internal id=fake session=d7caa3a payload={  "timestamp":1786863588506,  "message":"unms: connecting to 57.131.24.77:443",  "logLevel":1 }

Aug 16 08:59:48 udapi-bridge[1522]: unms rx: name=unms-startPing socket=internal id=fake session=d7caa3a payload={  "pingHost":"57.131.24.77",  "pingIntervalWhenUp":30000,  "pingIntervalWhenDown":5000 }

Aug 16 08:59:48 udapi-bridge[1522]: INTERNALAPI recv: sk: internal, name: unms-startPing, id: fake, 0

Aug 16 08:59:49 udapi-bridge[1522]: 57.131.24.77: 0.025ms, avg: 0.085ms (+/-0.025ms^2), min: 0.085ms, max: 0.000ms, loss: 0.00%

Aug 16 08:59:50 udapi-bridge[1522]: 57.131.24.77: 0.025ms, avg: 0.555ms (+/-0.025ms^2), min: 0.320ms, max: 0.000ms, loss: 0.00%

Aug 16 08:59:51 udapi-bridge[1522]: ping 57.131.24.77: 25.320000

Aug 16 08:59:53 udapi-bridge[1522]: LLDP: Touching DB entry (local port 1, name: eth0): from: e4:38:83:dd:53:6b , remote port: 'eth4' (type: 'Locally assigned'), ttl: 240

Aug 16 09:00:09 udapi-bridge[1522]: connection error (unms.faresoftware.it:443): Timed out waiting SSL

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-status, id: fake

Aug 16 09:00:09 udapi-bridge[1522]: session_destroy: session UNMS(0x49df98) not found

Aug 16 09:00:09 udapi-bridge[1522]: unms rx: name=unms-status socket=internal id=fake session=d7caa3a payload={  "timestamp":1786863609001,  "message":"connection error (unms.faresoftware.it:443): Timed out waiting SSL",  "logLevel":3,  "statusTe

Aug 16 09:00:09 udapi-bridge[1522]: unms: connecting to 57.131.24.77:443

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-status, id: fake

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI send: sk: internal, name: unms-startPing, id: fake

Aug 16 09:00:09 udapi-bridge[1522]: unms rx: name=unms-status socket=internal id=fake session=d7caa3a payload={  "timestamp":1786863609506,  "message":"unms: connecting to 57.131.24.77:443",  "logLevel":1 }

Aug 16 09:00:09 udapi-bridge[1522]: unms rx: name=unms-startPing socket=internal id=fake session=d7caa3a payload={  "pingHost":"57.131.24.77",  "pingIntervalWhenUp":30000,  "pingIntervalWhenDown":5000 }

Aug 16 09:00:09 udapi-bridge[1522]: INTERNALAPI recv: sk: internal, name: unms-startPing, id: fake, 0

Aug 16 09:00:10 udapi-bridge[1522]: 57.131.24.77: 0.034ms, avg: 0.514ms (+/-0.034ms^2), min: 0.514ms, max: 0.000ms, loss: 0.00%

Aug 16 09:00:11 udapi-bridge[1522]: 57.131.24.77: 0.025ms, avg: 0.485ms (+/-0.030ms^2), min: 0.000ms, max: 0.040ms, loss: 0.00%

Aug 16 09:00:12 udapi-bridge[1522]: ping 57.131.24.77: 30.000000

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Sending LLDP packet on port 1 (eth0)

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Some data on port 2 (eth1) were not sent

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Sending LLDP packet on port 2 (eth1)

Aug 16 09:00:19 udapi-bridge[1522]: LLDP: Sending LLDP packet on port 3 (wifi0)

How can solve this?

Best regards,

MZ

I'm experiencing a strange issue with several UISP-S switches. (all have the newest available Version, UISP has 3.0.159)

As long as the switches are connected to and managed by the UISP controller, they generate RSTP topology changes exactly every 8 hours. This results in MAC table flushes and unnecessary network reconvergence, even though there are no physical link changes, no device reboots, and no configuration changes.

What I observed

• Multiple UISP-S switches are managed by UISP.
• Every 8 hours, the switches report RSTP topology changes.
• The timing is very consistent and repeats continuously.
• The network itself is physically stable.

Troubleshooting

To isolate the problem, I performed the following test:

1. Put all UISP-S switches into Maintenance Mode. (UISP-S-Plus are working)
2. Removed the UISP URL from each switch so they were no longer connected to the UISP controller.

After doing this:

• The RSTP topology changes completely stopped.
• The network has remained stable for an extended period.
• No more periodic topology change events occur.

When the switches are reconnected to UISP, the problem returns.

Network

• UISP-S and UISP-S Pro switches
• RSTP enabled
• Managed through UISP
• Stable Layer 2 topology
• No loops or unstable links detected

Question

Has anyone else experienced periodic RSTP topology changes every 8 hours while UISP is managing UISP-S switches?

It appears that something in the communication between UISP and the switches may be triggering RSTP events, although I have not yet identified the exact mechanism.

Any ideas or confirmation from other users would be greatly appreciated.

Thank you!

We have a semi-public wi-fi network (which I don't administer) with several access points (each a different SSID), fed by a starlink system. At one location the wi-fi signal isn't quite strong enough for handheld devices to access, so I'm using the Rocket with an Omni antenna as a wireless client (station) with an Ethernet connection to the WAN port of another [consumer grade] Zoom router for devices in the immediate area.

The public network assigns IPs in the 192.168.1.x range. I've set up the Rocket for station wds wireless mode, and bridge for network mode. It generally shows a good wireless signal from the public AP in the -70 to -77 dbm range.

The local Zoom gets a DHCP IP address passed through the Rocket (currently 192.168.1.232) on its WAN port, and gateway and DNS are both 192.168.1.1. On the wireless side, the local route assigns IPs in the 192.168.2.x range.

The issue is that while it works well for the most part, I frequently lose Internet connectivity. I can still connect through to the Rocket at 192.168.1.20 and see that it's associated with the public AP with a good signal, but "no Internet" and pinging an outside IP like 1.1.1.1 fails. Then after a minute or two it just works again.

If I connect a device directly to the public AP (obviously I have to get closer to the AP to get a strong enough signal) I don't experience these interruptions.

I seem to recall a similar problem some years ago when I was administering the network (a completely different system) and it was resolved IIRC with an gateway and/or DNS change, but I don't really remember the details. Do I need to set those manually in the local router or is the default 192.168.1.1 correct?

Or would I be better setting the Rocket as a router instead of bridge and using the Zoom router as a simple AP?

I also tried disabling DHCP and NAT on the Zoom router making it into a simple AP (?) but then the local devices never get an IP.

https://uisp.community.ui.com/releases/86253408-92da-4cd7-9391-784d85a1ffcc?replyId=c8a4a507-7dfb-45f8-bbfa-90691a716315

But.. what an unpleasant surprise..

You can only setup basic things. You are forced to use app.

You can't set any network settings if port is unplugged. So you can't prepare the router before hand.

The app thinks it is smarter than you all the time.

What a disaster.

And now. After all the hassle I can't even set up dhcp-relay.

What is going on?!

If God gave this router to Adam & Eve and asked them to use Ubiquiti devices to build up Internet in the Great Garden they would not be able to, because uisp-r would be forever complaining that Internet wasn't plugged into Port 1.

To be polite I should maybe say at least one positive thing about the device. Maybe this - power supply looks solid (but the jack connector feels rather cheap).

Are we going to get ARP inspection and IP Source Guard on the Switch Plus, and why does the Switch Pro have a maximum of 256 entries for the binding table? We need the Switch Plus/Pro to catch up to EdgeSwtich in terms of switching features.

Or even better, abandon the failed GUI only / Unifi clone attempt, and introduce more 10G/2.5G solutions to the EdgeMAX products that are still currently being produced.

Did you guys hire Gavin Belson from Hooli?

In the ISP space we are not looking for point-and-click simplicity. We need command line power!

I have suffered a bit with the ipsec site-to-site and remote access configs on my two edgerouter 12.

Hence wanted to share the bugs I found with ChatGPT's help, hopefully will help someone else and with some luck they get fixed in a future release.

Cheers!

ChatGPT's write up:

# EdgeOS / VyOS IPsec & Agile VPN Bug Report

## Bug 1: Duplicate X.509 Private Key Entries Generated in `ipsec.secrets`

### Component

`/opt/vyatta/sbin/vpn-config.pl`

Function:

``` perl

sub get_x509_secret

```

### Description

When multiple site-to-site IPsec peers use the same X.509 private key,

the generated `/etc/ipsec.secrets` contains one identical `: RSA` entry

per peer instead of a single entry per key file.

Example generated output:

``` text

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

```

### Steps to Reproduce

1. Configure multiple site-to-site peers using the same X.509

  certificate and private key.

2. Commit configuration.

3. Inspect:

``` bash

cat /etc/ipsec.secrets

```

### Expected Result

Each private key should appear only once:

``` text

: RSA /etc/ipsec.d/private/paju.wlop.net.s2s.key.pem

```

### Actual Result

One identical entry is generated per peer.

### Consequences

- Unnecessary duplication in generated configuration.

- Causes StrongSwan to repeatedly load the same private key during

  startup and reload operations.

- Increases startup and configuration processing time.

- Becomes increasingly inefficient as the number of tunnels grows.

### Root Cause

`get_x509_secret()` always emits a new secret entry and does not consult

the existing `%key_file_list` deduplication mechanism already used

elsewhere in `vpn-config.pl`.

### Proposed Fix

Before generating the secret entry:

``` perl

return '' if defined($key_file_list{$key_file});

$key_file_list{$key_file} = 1;

```

Only emit the `: RSA` line when the key file has not already been

processed.

------------------------------------------------------------------------

## Bug 2: Agile VPN Generates Incorrect `rightca` Value

### Component

`/opt/vyatta/share/perl5/Vyatta/AgileConfig.pm`

### Description

The generated Agile VPN configuration uses the local configured CA when

generating the StrongSwan `rightca=` directive instead of the configured

remote CA.

### Steps to Reproduce

1. Configure Agile VPN with distinct local and remote CA certificates.

2. Generate Agile VPN configuration.

3. Inspect the generated connection definition.

### Expected Result

``` text

rightca=<configured remote CA>

```

### Actual Result

``` text

rightca=<local CA>

```

### Consequences

- Certificate validation may be performed against the wrong CA.

- Interoperability problems when local and remote trust anchors

  differ.

- Can lead to failed authentication or incorrect trust validation.

### Root Cause

The Agile configuration generator uses:

``` perl

$self->{_x509_rcacert}

```

when constructing `rightca=` instead of the remote CA variable.

### Proposed Fix

Use the configured remote CA when generating:

``` perl

$right_ca = "rightca=" . $remote_ca;

```

instead of referencing the local CA object.

------------------------------------------------------------------------

## Bug 3: Agile VPN Regeneration Is Not Triggered By Site-to-Site IPsec Commits

### Components

- `/opt/vyatta/share/vyatta-cfg/templates/vpn/ipsec/remote-access/node.def`

- `/opt/vyatta/share/vyatta-cfg/templates/vpn/ipsec/node.def`

### Description

Agile VPN configuration regeneration is only attached to the

`vpn ipsec remote-access` configuration tree.

Changes under:

``` text

vpn ipsec site-to-site

```

invoke `vpn-config.pl` and regenerate IPsec configuration, but do not

invoke `vyos-update-agile.pl`.

As a result, Agile VPN configuration can become stale or be partially

overwritten after unrelated IPsec changes.

### Steps to Reproduce

1. Configure Agile VPN.

2. Configure one or more site-to-site tunnels.

3. Commit.

4. Modify only a site-to-site tunnel parameter.

5. Commit again.

6. Observe that `vyos-update-agile.pl` is not executed.

### Expected Result

Any IPsec commit affecting generated IPsec configuration should trigger

Agile VPN regeneration.

### Actual Result

Agile VPN regeneration occurs only when something under:

``` text

vpn ipsec remote-access

```

changes.

### Consequences

- Agile VPN generated configuration can become inconsistent with

  current IPsec configuration.

- Site-to-site commits and remote-access commits follow different

  regeneration paths.

- Configuration correctness depends on commit order and on whether

  remote-access settings have changed recently.

### Root Cause

The regeneration hook exists only in:

``` text

vpn/ipsec/remote-access/node.def

```

and not at the broader:

``` text

vpn/ipsec

```

level.

### Proposed Fix

Attach Agile regeneration to the IPsec configuration tree itself so that

all IPsec-related commits invoke:

``` bash

sudo /opt/vyatta/sbin/vyos-update-agile.pl

```

Additionally, ensure template priorities are ordered correctly to avoid

priority inversion warnings when both IPsec-level and

remote-access-level hooks are present.

------------------------------------------------------------------------

## Summary

Three independent issues were identified:

1. Duplicate X.509 key entries generated in `ipsec.secrets`.

2. Incorrect CA reference used when generating Agile VPN `rightca`.

3. Agile VPN regeneration not triggered by site-to-site IPsec commits.

All three issues are reproducible on EdgeOS 3.0.1 / StrongSwan 5.6.3 and

affect generated IPsec configuration rather than user configuration.

We use snmp oid .1.3.6.1.2.1.17.1.1.0 for determening switch mac address but this snmp oid does not return uisp poe switch mac address

We found that usip poe switch mac address can be found using oid

.1.3.6.1.2.1.55.1.5.1.8.3

@UI-Team may be it can be fixed?

*intente varias formas para configurar el correo SMTP para envió de correos y no salgo del error “SMTP server connection is not working properly. SMTP configuration was reverted back”

*Otro punto es que logre meter mi backup del uisp cloud al uisp local server, me costo mucho trabajo pero pude hacerlo funcionar con un dominio en cloudflare, puedo verlo desde mi app y desde fuera de mi red. El problema que tambien presento es: todas las AP Rocket 5ac lite, y las estaciones litebeam 5ac si me las reconoció el servidor y me aparecen en lineá, pero todas las estaciones con litebeam m5 de primera generación me aparecen fuera de lineá, ya intente meter la nueva key, pero no logro hacer que se visualice en UISP Local server. Ojala que puedan ayudarme.

I ended up switching out my docker UISP server for the UISP-Console so I dropped the Unifi device on that side of VPN and am going through the new console.

Tried setting up firewall on my own and then I followed this:

https://community.ui.com/questions/UISP-Console-firewall-rules-for-VPN/ab8bf1db-84e0-4c21-b4e0-5f63c3b01286

I was on righttrack but did not use the Group negation. Now it half way works.

Now the only problem is:

Tower Network. 192.168.200.0/24

UISP Network 192.168.210.0/24

When I am on the tower network and try and connect to devices on 210.0 I can.

When I am on the UISP network and try to connect to devices on the 200.0 network, I can't.

here are the two firewall and one Nat rule.

Tower Connection is UNIFI router setup for zone firewall. This was working fine when setup was UNIFI router to UNIFI router. But moved to the console device. So I had to do nothing on the tower side.