@lifespeed

So, don't select that. I don't know what you've done, but sometimes it's best to start from scratch, in case you did something you shouldn't have. Perhaps there's someone else here, who can help you with Comcast. My experience is with Rogers, where IPv6 works well.

I don't know why, but it started again on Sunday:

Tue, 03 Mar 2020 02:00:18 +0100 (system): Scheduled backup Wed, 04 Mar 2020 02:00:19 +0100 (system): Scheduled backup ------- Sun, 24 May 2020 02:00:38 +0200 (system): Scheduled backup Mon, 25 May 2020 02:00:37 +0200 (system): Scheduled backup

I haven't changed anything (not even a reboot).

I have no good reason for using 8.8.8.8; I did this as part of trying to diagnose this issue, as the behaviour I was observing was that the internet was unavailable, but the gateway was still reporting as up, my supposition was that the ISP was prone to upstream failures - but I can revert this.

I don't follow the recommendation (my lack of knowledge). Are you saying that the gateway alarm is result in openvpn restarting, and (for some reason) - that this resulting in being me unable to make connections outbound from LAN to WAN?

Yes found that yesterday while fiddling with sysctl ;)

Made a PR to update the doc : https://github.com/pfsense/docs/pull/125

So I created a script in /usr/local/etc/rc.d/ containing

/sbin/ifconfig re0 promisc

which solves the problem. But why all of a sudden pfsense started behaving like this?

AFAIK the Interface statistics are pulled from netstat counters and there is no way to reset them from the command line. The one and only way is to reboot.

-Rico

This got me today. I can confirm the floating rule for ICMP solves the issue.

@stephenw10 Thanks a lot for your response Steve. I have just given up and factory reset pfsense. But your comment will be useful when I setup PIA (Yeah abbreviations are hard lol) VPN in a later date.

You can also achieve this with telegraf and the exec plugin (sysctl)

Got it. I have no issues waiting for p1 to appear I'm just trying to look at this as a learning opportunity.

Thanks for all your help @teamits.

Software update on Mikrotik from 6.44.1 to 6.46.6 solved the problem.
Sounds like Pfsense is handling some things a little bit differently than client/consumer OSes and this was an issue for Mikrotik.
Thanks for help.

I installed in ZFS pfsense test environment

I'm still trying, working for now, I continue sudden closings

I will install on the real system when I get results

Glad to report it's fixed. After several existential crises I found the problem. Ends up while I was doing 498758967456798430674551 different things, I swapped some ports around, and got some bad routes. For whatever reason, PFSense preferred the bad routes to the good one. So I just went to "Diagnostics --> States --> Reset States" and reset all (literally the only option).

Anyway, after giving everything a minute or two....it all just worked. I have no idea why those routes didn't clear out, but it's CERTAINLY a tool I'll remember in the future!!!

+1
there you go. ;-)

-Rico

my rsyslog.conf under ubuntu rsyslogd 8.32.0

# provides UDP syslog reception module(load="imudp" timeRequery="8" batchSize="128" threads="2") # needs to be done just once input(type="imudp" port="514") if $programname == 'dhcpd' then /var/log/pfsense-dhcpd.log & stop cat /var/log/pfsense-dhcpd.log May 20 19:29:37 172.16.0.254 dhcpd: Internet Systems Consortium DHCP Server 4.4.1 May 20 19:29:37 172.16.0.254 dhcpd: Copyright 2004-2018 Internet Systems Consortium. May 20 19:29:37 172.16.0.254 dhcpd: All rights reserved. May 20 19:29:37 172.16.0.254 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ May 20 19:29:37 172.16.0.254 dhcpd: Config file: /etc/dhcpdv6.conf May 20 19:29:37 172.16.0.254 dhcpd: Database file: /var/db/dhcpd6.leases May 20 19:29:37 172.16.0.254 dhcpd: PID file: /var/run/dhcpdv6.pid

you also need to check centos firewall/selinux

The OpenVPN gateway IP may not respond to ping. Try setting some other external IP to monitor across it.

@Gertjan said in Disable nginx access log (to remote syslog server):

True, these "access logs" are not really needed and do pollute de remote log.

@arrmo said in Disable nginx access log (to remote syslog server):

/var/etc/syslog.d/pfSense.conf

Noop.
This is the one that controls syslogd : /etc/syslog.conf

Yes, agree with you! I was thinking filtering at syslog, but I like your idea better 😄

It's build here 985 -> 1080 in /etc/inc/system.inc

I tried to rebuild somewhat the last statement :
Mine is :

*.* @192.168.1.4

so it excludes logs from 'nginx' as a program, or "Local5" as the facility, but no access.

OK, you lost me there, sorry. With *.* ... everything gets sent across, no? I may be missing your point.

It's also possible to inform nginx to shut up. See line 1447 :

access_log syslog:server=unix:/var/run/log,facility=local5 combined;

in the same system.inc file.

What somewhat seem to work without any pfSense file edits :

Yes, agreed! I like this approach. I changed that line to ,

access_log off;

And voila, after a webConfigurator restart (to regenerate the needed files) ... no "noise" from the access log. I think this is the best way to go, agreed?

Another solution : On the remote site, filter out Local5.Info messages

Right, but that still means all those messages going across => lots of bandwidth and horsepower chewed up (for no good reason ... agreed?)

Thanks for the thoughts and pointers - much appreciated!

After you make any change to LDAP SSL settings, run 16 and 11 from the console menu (ssh or physical console). Then test things again.

PHP gets weird sometimes when populating the environment variables needed for LDAP to work.

Unfortunately the PHP settings to configure LDAP directly don't work.

On 2.5.0 you could have both CAs added to the trust store for the OS which would also likely solve it.

Use the dual-home backup server if that's what you need. Make sure it cannot route between them though.

If routing between those subnets is restricting the throughput then look into where that is. pfSense maxing out the CPU?

You should be using different interfaces for the subnets, VLANs at least but preferably two NICs so you are not seeing throughput killed by the ACK traffic.

Steve