Please create helpdesk ticket on https://go.netgate.com/

I'm an ID-IoT. I forgot to tag the system port 5 as well. It was a little non-obvious.

@Evanc9126 said in SG-5100 gigabit throughput with UTM packages?: @bmeeks Thanks for the detailed explanation. I do run multiple VMs all of which can connect online so I'd imagine the packet payload is pretty high. My current router is capable of 2 million pps so if the SG-5100 is comparable to that, then it may not be worth the upgrade. I might have to go a step further to Xeon D. Here is a link to the Netgate hardware comparison table. This shows (on page 2 of the PDF) all of the current Netgate hardware and what the throughput is for each model with a few different traffic types. The type that likely is most applicable to your case is the one called "IMIX", which is a combination of large and small packets intended to mimic what most production networks would typically see. https://info.netgate.com/hubfs/website-assets/netgate-hardware-comparison-doc.pdf.

I restored from a recovery image and it looks like it's reinstalling missing packages now, thanks for helping get me on the right path!

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: [image: 1587490030302-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