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

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

It depends on the OS. The main hurdle you'll have is that it only has a serial console and that console is on what most operating systems would refer to as "com2". You can look over the instructions we have for booting other operating systems on that hardware at https://docs.netgate.com/platforms/rcc-ve-4860/install-guide.html -- the specifics will vary depending on the OS. Some of those are a bit out of date since we haven't sold that hardware in a while, but the general suggestions should still apply.

so i ended up finding the issue a console was not set to a static IP and threw the whole system is a mess but now is acting a lot better and I can get around an A-B without traffic shaping the only issue i really have now is only one wifi band on my router is getting good wifi speeds

I would configure that as a standard interface for an HA pair and see what happens. Troubleshoot it if there are issues. Steve

There is no straight forward way to do this for the reasons you found. There is an open feature request for it: https://redmine.pfsense.org/issues/4499 You can apply those settings to the lagg member interfaces using ifconfig at the command line. Thus you can also apply them at every boot using a shellcmd if that is required in your setup. https://docs.netgate.com/pfsense/en/latest/development/executing-commands-at-boot-time.html Steve

@jake Not really. I ended up returning it as we couldn't get the XG-7100 to work with the SFP. The XG-7100 had a few quirks due to the internal switch but that shouldn't have made the SFP not work. All the other units I had from Netgate (different models) worked extremely well. The few issues I did have were fixed quickly and directly. I did purchase a media convertor for the SFP to 1G-BaseT as a potential workaround but didn't end up using it.

Ok thank you and sorry to have put the mess in the topic. I thought that the topic was almost the same. Yann.

Ah that is just their main office hours, not the support hours ;) Makes sense now..

It could be if the extra ram has increased the boot time beyond the watchdog timeout perhaps. Try disabling that in the BIOS. Steve