Messages

1

General Discussion / Re: Anyone using ZeroTier? Can it be used with dual WAN for vpn failover?

« on: July 13, 2019, 07:16:09 am »

I use ZeroTier but not with dual WAN yet. I like it, it works well and is reliable. But cant comment on dual WAN. In theory it should work.

2

19.1 Legacy Series / Re: 19.1.1 Alias API fails to retain data or create new alias

« on: February 11, 2019, 04:54:30 am »

It might be a bug, but then alias_util is no substitute for the actual alias endpoint which was written for general add / remove / edit.


Cheers,
Franco

Might be a dumb question, but SHOULD one be used over the other? This is for external scripts/etc.

3

19.1 Legacy Series / Re: Aliases API in 19.1

« on: February 11, 2019, 04:53:20 am »

For anyone else that digs this up, this was fixed with a patch.

https://github.com/opnsense/core/issues/3214

4

19.1 Legacy Series / (SOLVED) Port alias tables not saving or persisting

« on: February 04, 2019, 10:34:13 pm »

Sigh. Well this is a non issue, I figured out that the actual ROOT issue is that my install of Home Assistant somehow picked up the Chromecast built into my Vizio TV even though the TV is on a separate subnet and firewall rules shouldnt allow anything. When HomeAssistant cant access a Chromecast device it hangs on startup with a unhelpful error. This whole thread was me erroneously troubleshooting the issues with Home Assistant getting to the Chromecasts that it should be able to, which it could all along I think.

Sorry for the alarmist thread.

5

19.1 Legacy Series / Port alias tables not saving or persisting (FW rules w/ port aliases dont work)

« on: February 04, 2019, 07:13:13 pm »

I have some port aliases that I use for some firewall rules. They seemed to stop working after the 19.1 upgrade, maybe right after or the next day. From what I can tell its because the port type aliases tables arent being persisted in rules.debug but I am not sure if they are supposed to be persisted.

I created a new alias, new firewall rule referencing it and still see the behavior below where port type aliases are not listed in pfTables under Firewall > Diagnostics, dont show up in pfctl and are listed in rules.debug but not persisted (which I am guessing they should be). I included a hosts type alias that does seem to be working.

The symptoms I end up seeing is that firewall rules referencing the ports alias dont work, that traffic isnt allowed and doesnt match the rule and thus gets dropped.

6

19.1 Legacy Series / Re: FQDN Based Firewall Rules

« on: February 02, 2019, 02:01:21 am »

If you create a hosts type alias with the FQDNs youre interested in you can then reference that alias in your rules. The IPs will be resolved from the alias. You can verify the list by going to Firewall > Diagnostics > pfTables and then finding the Alias you created. I seem to recall that it needs to be referenced in a rule before it shows up there.

7

19.1 Legacy Series / Aliases API in 19.1

« on: February 02, 2019, 01:47:05 am »

I have a fail2ban script setup that will add and remove IPs from a hosts alias. It was working with 18.7.9 but post upgrade to 19.1 it seems a bit strange. It seems like alias_util is overwriting the alias with a delay.

Adding IP works but the previous IPs seem to get deleted right after. It isnt my fail2ban script, I am running these manually for the below test.

root@cerberus:/home/admin # pfctl -t BANNED -Ts
   1.0.1.4

Doing the add from another host:
curl -XPOST -d '{"address":"1.0.1.10"}' -H "Content-Type: application/json" -k -u "key":"secret" https://cerberus/api/firewall/alias_util/add/BANNED
{"status":"done"}

Table updates correctly as expected:
root@cerberus:/home/admin # pfctl -t BANNED -Ts
   1.0.1.4
   1.0.1.10

Here I did not call the reconfigure part of the API yet, but now the table reverts to only one entry (the most recent one) within 30 seconds:
root@cerberus:/home/admin # pfctl -t BANNED -Ts
   1.0.1.10

I tried host and network type aliases and its the same behavior. If I add through the UI then both entries stay. Adding a third through alias_util causes the earlier ones to be deleted.

I could be misunderstanding the API but since it worked in 18.7.9 I suspect this is a 19.1 bug?

8

Hardware and Performance / Re: Fitlet2 J3455 alternative?

« on: January 10, 2019, 11:13:49 pm »

Whats wrong with the fitlet2 itself? Its onboard NICs are Intel i211s and its FACET add in card its two more i211s. So a total of four Intel NICs.

9

19.1 Legacy Series / Re: HAProxy - Support for GPC General Purpose Counters

« on: January 09, 2019, 05:57:46 am »

Will do, thank you!

10

19.1 Legacy Series / HAProxy - Support for GPC General Purpose Counters

« on: December 27, 2018, 10:47:58 pm »

Im not sure if this goes here or on Github but does anyone know if UI support for gpc stick tables and rules/acls is planned for the HAProxy plugin? Gpc being General Purpose Counter.

Its used most often in the abuse prevention type rules.

Some examples:

https://www.haproxy.com/blog/bot-protection-with-haproxy/
https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#7 (search for gpc0)

Code: [Select]

frontend http
    # Use General Purpose Couter 0 in SC0 as a global abuse counter
    # protecting all our sites
    stick-table type ip size 1m expire 5m store gpc0
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc0_get_gpc0 gt 0 }
    ...
    use_backend http_dynamic if { path_end .php }

backend http_dynamic
    # if a source makes too fast requests to this dynamic site (tracked
    # by SC1), block it globally in the frontend.
    stick-table type ip size 1m expire 5m store http_req_rate(10s)
    acl click_too_fast sc1_http_req_rate gt 10
    acl mark_as_abuser sc0_inc_gpc0(http) gt 0
    tcp-request content track-sc1 src
    tcp-request content reject if click_too_fast mark_as_abuser

11

18.7 Legacy Series / Re: Firewall API use

« on: December 14, 2018, 06:57:55 pm »

I noticed this same behavior too. I even verified that it happens even if the alias is referenced in a firewall rule or not referenced in a firewall rule as I thought that could be it, but it happens either way. Basically if the host type alias is empty then there is an error on API posting an address. I tried a few variations such as 1.0.32.1/32 (returned an error about invalid address like the alias was empty) and 1.0.32.1\32 (returned "not an address").

This is the error if the alias is empty:
{"errorMessage":"[OPNsense\\Firewall\\Alias:aliases.alias.c87dab5e-d37b-4bb0-9f01-ec950f0891b7.content] Entry \"\" is not a valid hostname or IP address.\n","errorTitle":"An API exception occured"}

I tried curl and PostMan, same in both. Adding one address in manually through the UI lets the API work immediately so its not that big a deal (in my opinion).

This is on 18.7.9 and I didnt do the patch referenced a few posts up.

12

Hardware and Performance / Re: 19" Hardware

« on: November 24, 2018, 09:57:25 pm »

I use one of these board/CPU combos. It will handle anything you can throw at it.
http://www.supermicro.com/products/motherboard/ATOM/X10/A1SRi-2758F.cfm

In a Supermicro SC505-203B 1U rackmount chassis
http://www.supermicro.com/products/chassis/1u/505/SC505-203B

That Supermicro board has four Intel NICs on it along with IPMI and a PCI-e slot that I have an Intel 10Gb SFP+ card in.

Other parts are 8GB of RAM (note the board takes ECC SODIMM) and SSDs. And some 40mm Noctua fans that are nearly silent.

13

18.1 Legacy Series / Re: Insight Aggregator logs?

« on: May 15, 2018, 02:11:33 am »

There is some information in this thread:
https://forum.opnsense.org/index.php?topic=3581.0

You can go into Reporting then Settings and reset the cache. If that doesnt work you can try deleting /var/log/flowd*.