Yes is back to normal again.

If someone wants to submit a PR to fix code in the 2.2.x package, that's fine. Though binary updates at this point are questionable.

We have no plans to do anything with the package on 2.3 directly; We did not create nor maintain the bind package ourselves, so it's unlikely we will be putting any of our own effort into doing anything with it on 2.3. The package was always a community submission, so the work to bring it 2.3, if it is going to be there, would have to be done by the community as it was before.

It looks like NOYB has done some recent work on that, not sure if it is related:

https://github.com/pfsense/pfsense/commit/4d3a100558ce505f52864c385a54411e25d54194

https://github.com/pfsense/pfsense/commit/2ebc9a38a09bd310d9da750cf22afae92d9343d8

IPv6 addresses have returned after the Gitsync… then I had to save/apply on WAN before anything actually worked.

Looks good. Thanks!

i added them through custom don't know it this will work here is what it looks like
then added static routes to correct gateways

Forwarding

forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 8.8.4.4
forward-addr: 2001:4860:4860::8888
forward-addr: 2001:4860:4860::8844

Unbound custom options

forward-addr: 209.105.180.20
forward-addr: 216.227.40.2
forward-addr: 166.102.165.32
forward-addr: 207.91.5.32

Thanks for clarification! :)

If you want any restrictive filtering rules on the traffic between VLANs, then you need to keep putting the traffic through pfSense, or use a layer3 device that also allows filtering that you want to do (which really = pfSense ;) ).

If you just want all traffic to be passed between the VLANs, then a layer-3-capable "switch" is good.

Yeah I fixed the text there, thanks.

@phil.davis:

Or ping something out on the real internet that should always be up and responding reliably - Google 8.8.8.8 and/or 8.8.4.4 for example.

That's my guess as to what'll keep that from being an issue, don't ping the ISP's router IP. And/or increasing the probe interval. Probably triggering some rate limiting on the ISP's side, which we've seen from at least one other here.

dpinger doesn't do anything to the interface even if it has loss or goes down (that only updates gateway groups with multi-WAN configs).

Thanks, it starts now.
Does not really work for me, though. I used it to forward SSDP on 2.2.6, which worked fine. I setup a 2.2.6 VM to confirm that it still works there. Also tried an older 2.3 beta without the new changes and without CARP. Errors below are the same.

On 2.2.6 I get:

$ netstat -gn IPv4 Virtual Interface Table Vif  Thresh  Local-Address  Remote-Address    Pkts-In  Pkts-Out   0        1  192.168.1xx.6                        340          0   1        1  192.168.2xx.105                        0        340 IPv4 Multicast Forwarding Table Origin          Group            Packets In-Vif  Out-Vifs:Ttls 192.168.1xx.11  239.255.255.250      100    0    1:1 192.168.1xx.31  239.255.255.250        12    0    1:1 192.168.1xx.30  239.255.255.250      134    0    1:1 192.168.1xx.245 239.255.255.250        42    0    1:1 192.168.1xx.36  239.255.255.250        12    0    1:1 192.168.1xx.246 239.255.255.250        40    0    1:1

on 2.3:

netstat -gn IPv4 Virtual Interface Table Vif  Thresh  Local-Address  Remote-Address    Pkts-In  Pkts-Out   0        1  192.168.1xx.2                          0          0   1        1  192.168.2xx.252                        0          0 IPv4 Multicast Forwarding Table is empty

And many complaints in the log about LAN hosts not being in any vaild net for WAN upstream, which seems kind of odd to me.

The source address 192.168.1xx.245 for group 239.255.255.250, is not in any valid net for upstream VIF.

Firewall rules on 2.2.6 and 2.3 are set to allow all IGMP incoming on either LAN and WAN with IP options, so no difference there.

It's not recorded anywhere outside the logs. That just records that it handed it out, no lifetime or anything. You don't get that type of info off DHCP static mappings in any widely-used DHCP server software.

Thanks!

I can only say that I will stick with pfsense `till the end :)

@M_Devil:

Found system->Advanced->Miscellaneous, section "RAM Disk Settings (Reboot to Apply Changes)"

Sizes are in MB and not like above abbreviation.

Pull request https://github.com/pfsense/pfsense/pull/2696

From what I can see, you are right. The underlying FreeBSD mdmfs utility creates a 40 MiB memory disk when -s 40m is specified.

Here is a link that provides a reasonable explanation of how rrdtool processes data. The section entitled "Normalize Interval" is the most applicable to your question as to why you see 41.9%. Enjoy.

http://rrdtool.vandenbogaerdt.nl/process.php

@bmeeks:

@maverick_slo:

Just a quick question…
Snort always downloads latest rules, how do we achieve this with Suricata? You have to specify file name of ruleset what to use there?
I'm familiar with snort but not with suricata :)

The rules for Snort are linked to the version of the binary.  You can't run older rules with a newer binary (or vice-versa).  It will print a version error and refuse to start.  The rules are named for the Snort binary version they are designed for.  The Snort package on pfSense uses a shell script trick to have the loaded binary print out its version information into a string.  This version number is then used to construct the download URL for the rules.  Hence you always get the proper rules for the loaded/installed Snort binary version.

Suricata has a completely different binary versioning scheme that in no way matches up with Snort.  Also, the two binaries get updates at different times.  So there is no way for Suricata to intrinsically "know" what the most current Snort rule set should be.  So instead, in the Suricata package, I provided a field where the user could specify the Snort VRT rules version they want to use.  That's really the only option.

Bill

Thanks Bill.

What have you tried so far? Did you use any of the tips we gave you?

Correct.