Just an update on this for anyone interested. This ended up being an issue on the Unifi switch side due to what appears to be a bug in the 4.3.13.11253 USW-Pro firmware. For some reason it was blocking tagged traffic from ix0.100 on the trunk port from reaching the untagged switch ports assigned to VLAN 100.

Hi all, Thanks for your input. I finally: contacted with NetGear Support got access to the lastest official image (2.4.5_p1) backed up the router installed the pfSense image restored the image and the problem was solved. I had tried, out of desperation, trying to switch back to the 2.4.4 train, but to no avail. I had no chance of trying @Tuco 's suggestion, which looks like a good solution to the problem. Thanks to everybody for chiming in.

Fixed, required firmware flash.

https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/reinstall-pfsense.html -Rico

Response from Netgate Support: "Powering that device with the USB port should be fine." Chris

@raboud do you think this is enough for your part ?! begin to describe your problem accurately, etiquette is very important just so you write in a nearly 1 year old thread..... -What would you like to know? -since there have been a lot of updates in 1 year, it may no longer be up to date what you would like to know ++++++ @Derelict Just forget about OPT1 being a member of the switch VLAN. That XG-7100 unit has a built-in switch. Bridging that with OPT1 will only slow things down as you will no longer be using switch hardware but will be using a software/CPU bridge. If you need OPT1 connected to a switch, connect it to a switch. If you absolutely need those XG-7100 ports to be on the same broadcast domain as OPT1, I would disable the trunk links back to pfSense (no 9t,10t tagged ports on the built-in switch on that VLAN) and patch it to your external switch.

@akuma1x said in How reliable is the XG-7100?: That's what the OP already ordered, an HA pair. d'oh! Read right past that first sentence.

Thanks for the info

@kiokoman thanks

@Gertjan thanks for trying that out. Eventually, I've restored a pfsense config backup since 1 month ago. I changed the password for pppoe and now it just worked. I still don't know what I did wrong the first time I tried but the important thing is that now I have pfsense correctly configured and working. Thanks for the support! G.

@jimp Thank you! Since I don't have an SG-5100 yet, I couldn't do that. Thanks for the verification. ADD TO CART

I believe you need a PCIe if you want to use the internal SIM slot. I think the USB ones are external ones anyway. Unfortunately, I don't have own experience (I have an SG-5100 as well, but I have no need for mobile broadband there), but none of the PCIe modems that I quickly checked seem to have a SIM slot. They are usually used in devices like notebooks that have the SIM slot separately as well (for the same reason, to have it at the right place to be accessible). I think one of the most important aspects when selecting a modem from the list are the mobile network standards (e.g. 2G, 3G, 4G, 5G) and the best set of frequency bands for your country.

Thank-you for documenting this - the setup worked for me too!!

Hello! In software engineering, some seemingly simple requests users make can be deceptively difficult to implement, whilst others that users perceive as incredibly complex are actually quite simple to crank out. The engineer can be seen as either a goat or a hero. It is not fair to presume where this request falls in that continuum, but you are free to roll up your sleeves, dive into the open source code, and make that determination for yourself. John

If you're getting that far, then that's a good sign at least. To me it looks like it's using the wrong console port past that point. The BIOS/initial boot is going to the right port but after that it may be switching to the wrong port. That's almost certainly the case for the pfSense USB image unless you used the correct one named "ADI". Linux bootable drives would have the same issue, you have to edit the boot parameters and tell it to use the right port. In each case you'll want to direct them to use com2 / 0x2F8 / console=ttyS1,115200n8 or similar depending on the OS.

If i reboot manually. After restore it does not automatically reboot.

[image: 1591150669945-9a557bff-ab84-4e71-9cd0-dc1d1a412508-image.png] Doesn't look to be at the moment. .27.1 is the latest on 2.4.5

Hello, Thanks all for the help. It looks good now. Looks like as @jimp mentioned there might be problem with package server. Thanks to all

Seems multi threading not working properly on pppoe:( #PPPOE interface not using all queues: [2.4.5-RELEASE][root@router.kilsol.com]/root: sysctl -a | grep '.ix.1..*x_pack' dev.ix.1.queue3.rx_packets: 0 dev.ix.1.queue3.tx_packets: 5535356 dev.ix.1.queue2.rx_packets: 0 dev.ix.1.queue2.tx_packets: 6279749 dev.ix.1.queue1.rx_packets: 0 dev.ix.1.queue1.tx_packets: 6031232 dev.ix.1.queue0.rx_packets: 51346277 dev.ix.1.queue0.tx_packets: 9096401 #Non PPPOE interface is using all queues: [2.4.5-RELEASE][root@router.kilsol.com]/root: sysctl -a | grep '.ix.0..*x_pack' dev.ix.0.queue3.rx_packets: 5396172 dev.ix.0.queue3.tx_packets: 81242 dev.ix.0.queue2.rx_packets: 6706346 dev.ix.0.queue2.tx_packets: 618190 dev.ix.0.queue1.rx_packets: 6020980 dev.ix.0.queue1.tx_packets: 174660 dev.ix.0.queue0.rx_packets: 7843425 dev.ix.0.queue0.tx_packets: 48490796 [2.4.5-RELEASE][root@router.kilsol.com]/root: #Tunables do indeed match # of cores [2.4.5-RELEASE][root@router.kilsol.com]/root: sysctl net.isr.maxthreads net.isr.maxthreads: 4 [2.4.5-RELEASE][root@router.kilsol.com]/root: sysctl net.isr.numthreads net.isr.numthreads: 4 #net.isr.dispatch was set correctly [2.4.5-RELEASE][root@router.kilsol.com]/root: cat /boot/loader.conf.local net.isr.dispatch=deferred