Hacker News new | past | comments | ask | show | jobs | submit login

And OpenBSD/octeon[0][1] appears to run on UniFi Security Gateway.

Just ~ two weeks a go I finally retired my old OpenBSD based gateway in favor of USG. But no, I guess I'm back to putting OpenBSD on USG, and maybe OpenWRT on APs.

Is there a working replacement OS for Ubiquiti PoE switches?

[0] https://www.openbsd.org/octeon.html [1] https://codeghar.com/blog/openbsd-on-ubiquiti-usg.html




Or just block the outgoing connection? What am I missing?

It’s not like it doesn’t already have a firewall built into it.


But here lies the dilemma: do I trust them? If I put in a rule to block their telemetrics, would USG honor that rule? Not just now, but after some firmware update that 'breaks' something. Or maybe I have to put another box in front of USG that I actually trust to be certain that call home got blocked. And even if I block this call home, maybe it changes to something else in next version or the next that now needs to be blocked as well. And maybe the data being sent home changes to more draconian over time as the marketing department gets greedier. And so it goes.

When I buy [network] equipment, it is my expectation that since I own the HW, I am to a certain degree in control of what they do and to whom they 'talk to'. And call-home / telemetrics without at least opt-out just doesn't sit well with me here.


You actually can't* use the firewall to prevent a USG or EdgeRouter from phoning home as the WAN_LOCAL rules only apply to inbound traffic.

* Possibly by some other combination of dropping Established/Related traffic. I think that'll get gnarly for the instances where WAN_LOCAL traffic is needed -- VPN, connectivity checks for load balancing, etc.


“eth0_in affects traffic entering the ER on eth0 that gets forwarded to somewhere behind the ER

eth0_out affects traffic leaving the ER on eth0

eth0_local affects traffic that enters the ER on eth0 and is targetted directly at the ER itself (e.g. the webgui)”

In this case you would put the rule on eth0_out, not eth0_local.


Not sure what you're quoting, but you are misinterpreting it. The IN / OUT rulesets absolutely do not impact traffic that originated from or is destined to the router itself.

Just now I verified with the following partial ruleset on a EdgeRouter I have in production:

  set firewall name WAN_OUT default-action accept
  set firewall name WAN_OUT rule 300 action drop
  set firewall name WAN_OUT rule 300 description 'block 1.1.1.1'
  set firewall name WAN_OUT rule 300 destination address 1.1.1.1
  set firewall name WAN_OUT rule 300 protocol all
  set interfaces ethernet eth0 firewall out name WAN_OUT
Devices behind that ER can no longer communicate with 1.1.1.1, but the ER itself can.

The only way to filter traffic from the router would be to drop the standard "Allow Established / Related" rule from WAN_LOCAL, retain the default drop action, and make specific rules allow whatever the router should be permitted to communicate with. And that would still allow packets to escape the router -- for TCP the communications channel is effectively dead since the handshake can never complete, but it could blast out all the UDP it wants.


Maybe read the Ubiquiti EULA. You don’t own the software.


I Just read a post at the link that said doing so causes the unit to retry and retry until restarting after so many tries. That’s not great.


There's a comment further down the page from ubuqiti that says they've fixed that.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: