• 0 Votes
    5 Posts
    794 Views
    B

    SOLVED! on my test rig I tried a state-killing option that had NOT solved the problem on my live box, but on the test rig it worked. The setting is in System/Routing/Gateways, "State Killing on Gateway Failure". After changing that from the default to "Kill states using this gateway when it is down", subsequent failover events created a few arpresolve errors in the log, but within 1 second they stopped, after an entry in the log showing a state killing action:

    /rc.filter_configure_sync: GW States: Killing states for dynamic down gateway: WAN_DHCP, XX.XX.XX.1

    After that worked, I had to figure out why this solved the problem with my test rig but not my live box. Eventually I traced it to a setting in System/Advanced/Miscellaneous in the Gateway Monitoring Section, "Skip rules when gateway is down". In my live box, which has some traffic that needs to be routed only through a VPN, I had enabled the setting "Do not create rules when gateway is down" years ago to make sure, if the VPN was down, that pfSense wouldn't route the traffic through the non-VPN WAN. But as soon as I cleared that check box, my failover arpresolve problem went away. So apparently that setting interacts with the failover in a way that prevents the state-killing action from working properly.

    Next job is to figure out a different way to kill VPN-bound traffic if the VPN is down... Googling that now.

  • 0 Votes
    11 Posts
    2k Views
    S

    Final reply to this thread for anyone in the future who needs to setup something similar:

    I've put the full solution, including the NodeRed flow here: https://gist.github.com/Slyke/7d5b290f1d5695fdd79f5e0a08837c93

  • 0 Votes
    85 Posts
    19k Views
    M

    @johnpoz said in SG-3100 switch weird behavior (resolved):

    once you put it up, I will give it a go via a VM maybe. I don't as of yet have a pi4 to play with.. Been looking for an excuse to get one hehe.. But they have been hard to find as well, I would prob go with the 8GB ram model as well.

    Done, english is not my first language so I hope its okay.

    https://forum.netgate.com/topic/175394/graylog-server-on-a-raspberry-pi

  • Two MAC address on LAN interface

    General pfSense Questions
    6
    0 Votes
    6 Posts
    875 Views
    M

    The problem has been resolved.
    I just needed to flush the ARP table on the client computers.
    Somehow the phisical interface MAC (4c:52:62:2b:57:6d) was in their table not the "CARP MAC" (00:00:5e:00:01:0c).
    Thats why the AV was fustrated.

    Thanks for the comments!

  • 0 Votes
    6 Posts
    1k Views
    M

    SOLVED - I figured out my problem. It was caused by this setting below (Static ARP under the DHCP Server configuration for the interface), which I had enabled on the interface because I interpreted it incorrectly. It essentially took precedence over any and all allow rules configured for the OPT2 interface, and prevented any host without a statically assigned DHCP address from communicating with the interface even though the host received the dynamic DHCP assignment from the OPT2 interface. I hope this saves other folks time and headache.

    Screen Shot 2019-11-06 at 9.46.34 PM.png

    As explained in docs.netgate[.]comScreen Shot 2019-11-06 at 10.40.04 PM.png