I'm using pfBlockerNG with DNSBL. The DNS only happens with power outage. There is no issue with DNS resolve with reboot. I've done several reboot with no issue with DNS.

@msf2000 said in SG-1100 NIC Offload - enable or disable?:

checksum errors with Suricata

With Suricata we always

check "Disable hardware checksum offload" (System->Advanced->Networking) disable ALL stream-events.rules or it will block lots of traffic on false positives

Otherwise we get the checksum errors also. https://forum.netgate.com/topic/122571/suricata-floods-the-log-with-invalid-checksum

Yeah. Packet capture on WAN for the gateway IP address and protocol ICMP.

Ping the gateway address using Diagnostics > Ping.

Stop the capture.

Do you see the echo requests go out? Are they replied to? You can also examine the MAC addresses there to determine that the source address is your WAN address and the destination address is the MAC address for the gateway IP address from the ARP table. There really isn't any way that would not be the case but it is worth checking.

Just set the level of detail to Full and hit view capture to see that. There is no need to capture again.

Ah, well you would be toward the top of the 3100s performance if you are hitting those speeds in normal use, especially if you are running any packages.
If that is the case an SG-5100 would certainly be faster.

Steve

@stephenw10 Thanks again - this was very helpfull.

I see that netgate included a FreeBSD Handbook under the diagnostics tab...

Bad port on the AP? Is that logging any disconnects still?

Hi Paul,
You should be able to able to do that as long as all the interface mismatches are corrected before you reboot.
If anything is still mismatched it will stop at the interfaces assign prompt in the console. Did you have the console open? I would bet that's what happened.

Steve

Ah, good. That had me questioning everything!

But, yes, the driver can only actually accelerate AES-128-CBC.

Steve

Hmm, nice catch. Interesting.

On the Interfaces > Switches > Ports tab you can edit the lagg group directly:

Selection_826.png

Steve

Indeed, there is no thermal sensor in the SG-1100 to measure so it cannot be displayed.

Steve

Ah, glad you were able to get something up and running. Still unclear why that was required though.

Steve

Hi,
Correct, no access after reset and with another device.
Submitted ticket.
Thanks

pftop output (copied from web UI) filtering on ICMP and showing pings going to 2.222 from pfSense and from a VPN client. (the pings from pfSense would work if there was something there to talk to).:

pfTop: Up State 1-4/4 (614), View: default, Order: bytes PR DIR SRC DEST STATE AGE EXP PKTS BYTES icmp Out 10.1.10.2:1487 10.1.10.1:1487 0:0 33:38:42 00:00:09 474338 13281464 icmp In 192.168.5.2:13206 192.168.2.222:13206 0:0 00:07:42 00:00:10 452 37968 icmp Out 192.168.5.2:13206 192.168.2.222:13206 0:0 00:07:42 00:00:10 452 37968 icmp Out 192.168.2.1:47732 192.168.2.222:47732 0:0 00:00:30 00:00:09 30 2520

Here it is w/ filter "net 192.168.2.0/24" without me doing anything:

code_textpfTop: Up State 1-2/2 (514), View: default, Order: bytes PR DIR SRC DEST STATE AGE EXP PKTS BYTES udp In 192.168.1.3:61633 192.168.2.101:161 NO_TRAFFIC:SINGLE 00:00:12 00:00:29 2 214 udp Out 192.168.1.3:61633 192.168.2.101:161 SINGLE:NO_TRAFFIC 00:00:12 00:00:29 2 214

Well lookie there, the cause of those lingering ARP queries! .1.3 is a Windows server; I guess it somehow heard that there was supposed to be a 2.101 somewhere and decided to start sending it SNMP queries? Go figure. Getting back on track...

Here's a couple of snapshots using the same "net 192.168.2.0/24" filter (I manually removed the .101 distractor, but it's otherwise untampered) showing me simultaneously trying to open a TCP connection to .2.222 from both the Netgate and the VPN client:

code_textpfTop: Up State 1-5/5 (509), View: default, Order: bytes PR DIR SRC DEST STATE AGE EXP PKTS BYTES tcp In 192.168.5.2:34340 192.168.2.222:22222 CLOSED:SYN_SENT 00:00:04 00:00:29 3 180 tcp Out 192.168.5.2:34340 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:04 00:00:29 3 180 tcp Out 192.168.2.1:39581 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:04 00:00:29 2 120 pfTop: Up State 1-5/5 (854), View: default, Order: bytes PR DIR SRC DEST STATE AGE EXP PKTS BYTES tcp Out 192.168.2.1:39581 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:24 00:00:28 7 420 tcp In 192.168.5.2:34340 192.168.2.222:22222 CLOSED:SYN_SENT 00:00:24 00:00:21 5 300 tcp Out 192.168.5.2:34340 192.168.2.222:22222 SYN_SENT:CLOSED 00:00:24 00:00:21 5 300

I don't see anything wrong at that point -- it seems to claim that it's at least planning to forward the SYN from the VPN client. Any more ideas on how to get a closer peek at where it's being dropped?

Hi Steve

Thanks for the reply.

Just the one,

However, it turns out I just connected it to the upstream ISP router and it registered the XG-7100 mac automatically. So I'm all good.

Time to read up on VLANs/LAGGs.

Cheers

pfsense hasn't dropped the internet once since they made a few changes in the Sonicwall. I asked what the Sonicwall Tech had to change. If I hear back I will post the solution for my issue in here in case anyone else runs into something similar. Thank you @Cool_Corona for your input

Thank you for a quick answer!
Can you please explain in some simple way how i set up pfSense?
Let us just use simple "VLAN1" and "VLAN2" and "VLAN3" as an example.
I have had the pfSense for a few days and just barely started to figure out some basic things in it so, well... almost starting to crawl, but only just. =)
And sadly my old router is about to.. die, any moment (already had a LOT of trouble with it today and with some CPR i have managed to get network in somewhat working order again after it just... stopped working this evening) so i really would like to just spend some money tomorrow to get somethings running properly again.
(Bad week this... power went out for a while yesterday (a bit windy...), water went out for a while today (giant water leak nearby) and now internet, and i have a young daughter that will have a real meltdown if internet doesn't work since she REALLY needs here favorite color videos on YouTube.)

@RJ said in SG-5100 Status LEDs:

Mine is flashing green, which I gather means update available. Add that too maybe?

I had to check that one, but yes flashing green means there is a pfSense update. Thanks! We'll get that added too.

Hmm, I imagine then it just removed the IPv6 bogons table which would otherwise be loaded causing pfctl to spike.

Open a ticket with the support, they can 100% help you out.
https://go.netgate.com

-Rico