Glad it's working! Just a note for down the road, eventually you will want to remediate your double NAT situation. In other words, have the ISP configure their modem in bridge mode, so PFsense gets a public IP.

Ok was definitely not the device upgrade, that didn’t happen till the 29th..

@stephenw10 Thank you very much for help and advice! Problem solved.

Unless you have disabled it pfSense will be NATing traffic for 192.168.1.1 to it's WAN IP, 10.65.1.2. Since we know the other side can ping that IP we know it has a route back, hence traffic from the pfSense LAN gets a response. But we don't know the remote side has a route to 10.65.10.X or 10.65.15.X. Nor do we know the MPLS infrastructure knows about those subnets. It looks like a missing route somewhere to me. Once you have that route in place you probably want to disable outbound NAT for 192.168.1.1 so devices at the remote site can see the correct source IP. That makes troubleshooting far easier for one thing. Steve

Install it and have a play it’s not hard to do. Also check out the pfSense videos, @BBcan177 goes over setting up pfblockerng. https://www.netgate.com/resources/videos/pfblockerng-on-pfsense.html

Yes, you will need to use the IGMP proxy to make this work and it will need to be at both ends since there are three subnet involved here. The only other thing you could do use an OpenVPN TAP connection but that would likely require significant network change and introduce other issues. Do you have to use that 'app'? It seems not well suited to your situation. Steve

Mmm, in fact it may not be required as it's a PPP link. I was thrown by your mentioning of DHCP. With a point to point link the traffic should reach the gateway even outside it's subnet. You may just need to set a different monitoring IP. The gateway might not respond to ping. Edit the PPP gateway in System > Routing > Gateways tab. Set, for example, 8.8.8.8 as the 'Monitor IP'. Steve

You should upgrade to 2.4.4p2 when you can. Try swapping the WAN and LAN NICs so that WAN is using the on-board real NIC. See if the failure moves to LAN. Ultimately there are no recommended USB NICs. If you're lucky you might find one that runs reliably. If you do find the LAN now fails after swapping them consider using VLANs and a managed switch instead. Steve

The difficulty with setting something like that up is that the wifi config in pfSense is not intended to connect to dynamically like that. There is no easy way to have it scan for wifi networks and present you with a choice to connect to. Or as you say to work past a captive portal. Though that could be done from a client the first time it connected as long as it wasn't being routed through a VPN that could not connect at that point! It's probably not practical currently IMO. Steve

It is possible to do that in order to use a public subnet directly: https://docs.netgate.com/pfsense/en/latest/book/bridging/index.html However it's far from ideal. It would be much better to have your provider route that subnet to you via a different IP that you can use on WAN. Then you can use the entire subnet on LAN and properly route between them. Steve

You don't have Google DNS defined anywhere there so that client may be using it directly. You should add a firewall rule above the VPN gateway rule to allow client to reach the pfSense LAN IP on port 53 to access Unbound. The OpenVPN server can be configured to hand a DNS server to the clients. It should probably be the local tunnel IP so that they use Unbound. Steve

This is the job of your webserver, not firewall/pfSense. -Rico

A harder way would have been to export your current config, edit out the traffic shaper details, reset your instance back to factory defaults and then imported the edited config. Glad you got it going again.

You can enable logging on the firewall rule that passes traffic for that. If it's passed by a catch-all rule you can add a more specific pass rule above that to catch only that. Steve

There's this for the firewall log: https://docs.netgate.com/pfsense/en/latest/monitoring/filter-log-format-for-pfsense-2-2.html But that's not really going to help you here. The gateway log messages should be pretty self explanatory. If it shows Alarm there's a problem. There is no system log list as that could potentially be any FreeBSD log message. Steve

Mmm, not clear what traffic you're seeing and where? Reading between the lines it sounds like you might have a misconfigured VLAN port somewhere that's become a member of all VLANs. But that's just a guess... Steve

Do you have a switch between the modem and pfSense? I would expect power cycling the modem to restore the connection if ifconfig donw/up works. Steve

@KOM Thank you! Regards, Mr. Teo En Ming Singapore 29 Mar 2019 Friday

@aharrison @Flole @chpalmer I believe I have a fix - I've been running this for about 20 minutes with no lag spikes. I won't call it ideal, or even great, but it proves without a doubt that the issue is with the 2.x builds of radvd and not a network card, or vlan or lacp or insert whatever excuse issue, it's radvd. I installed an older 1.x binary I was able to find on the freebsd packages mirror to replace the 2.17 binary. It seems to work perfectly fine (it's advertising as expected) and no more lag issues. Steps below (1.15 was the newest version I could find): First stop radvd (disable advertisements from the GUI) next you need to ssh into the system and go to the console cd /usr/local/sbin mv radvd radvd.bak mv radvdump radvdump.bak cd /tmp fetch http://pkg.freebsd.org/FreeBSD:10:amd64/release_3/All/radvd-1.15.txz tar xf radvd-1.15.txz cd /tmp/usr/local/sbin cp radvd* /usr/local/sbin/ restart radvd from the GUI and you should be good to go. Hopefully someone at netgate will address this more formally. As far as I can tell at this point it breaks nothing. If you do run into issues you should have no problem backing out, just delete the radvd and move radvd.bak to radvd.