It's been while since I tried it but I think you had to deploy it as a profile to OSX to use anything but the default options there. However since that hangout was made I also think OSX may have stepped up the encryption levels it uses by default... so maybe a bit of both in play here. I know at the time we chose those settings as the only thing that would work with everything. Try setting it to the values in the hangout to make sure it connects and it is a encryption settings issue. If so look at deploying via a profile. Steve

You might be able to do this by making use of the option: Skip rules when gateway is down. That's a setting in System > Advanced > Misc. It applies globally so you would have to be careful. With that set use two rules on the LAN to pass traffic. The first via the main gateway. The second via the LTE gateway with limiters set. If the main gateway goes down that rule will not be applied and traffic will hit the second rule. Add copious notes because that would be an unusual setup, highly likely to confuse anyone who sees it later. Steve

@stephenw10 Oh, I have got the impression that it is also related to older versions. Thank you.

@stephenw10 Turned out to be a gateway issue. Had a little trouble getting the gateway off one adapter and onto another. Wanted to create a new duplicate gateway if changes were made in the wrong order. So took a couple runs through restoring the desired config then modifying the adapter ip/gw, deleting an associated vlan, disabling monitor action, and reassigning the gateway to get update working. Confirmed in backup router that "pkg -d updates" produces the same results as the in-service router. Left the packages behind but they can be manually reinstalled easy enough. Now golden. Thanks so much Stephen for your assistance. Much appreciated.

The Three Data Reward SIM is PAYG but you get 200MB per month free so it effectively costs me nothing until I need to use it when I then have to add credit. It's more expensive at that point especially if I have to use it quite a lot and much less convenient, requires manual intervention. But... hard to argue with free. Steve

It depends how they are being 'detected'. If they are entered into hosts by IP, the best way IMO, they should always be visible. If they dependent on some broadcast domain style detection protocol then you would need something to proxy/bridge that between subnet. So Avahi for mDNS or IGMPproxy / PIMD for SSDP. If they seen by your DC you may not need any of that of course. Steve

Good luck. Though you should be good. As I say the biggest risk there is that you pull in a bunch of changes that may have been added and were not yet in effect. If rules there do not change often then that may not apply. Steve

Good to hear to got access at least. That sort of situation can be inconvenient. There is no off-line upgrade option currently. You can upgrade from the console menu as long as you have a functioning WAN. You might consider switching to a full HA setup if you can get enough WAN IPs. Steve

@stephenw10 Awesome, much thanks Steve!

Yes choose option 1 at the console menu and re-assign the interfaces as required onto the new NIC. You will have to recreate the VLANs there though so they are also assignable if you have those interfaces in place already. Steve

Ok, you don't have a gateway set on the LAN rules so you are not policy routing. In which case you should be able to connect to those IPs directly as long as they are in the same subnet as your WAN. Are they? Can you ping them from pfSense in Diag > Ping? You have filtering disabled on both the bridge members and the bridge itself. That's not normally how it would be configured, most people want to filter the traffic to the hosts in the DMZ. Steve

@stephenw10 Hi Stephen, yeah I figured it out in the end... Now just have to get the Mac's working ! :-)

@manjotsc Worked after changing to from this https://www.youtube.com/watch?v=Qz68aZ6Yf5g&t=279s "plink -no-antispoof -P 8934 -i C:\Users\admin.ssh\id_rsa_putty.ppk root@192.168.40.1 tcpdump -i igb2 -U -w - not tcp port 22 | "C:\Program Files\Wireshark\Wireshark.exe" -i -k" to "C:\Program Files\PuTTY\plink.exe" -no-antispoof -P 8934 -i C:\Users\admin.ssh\id_rsa_putty.ppk root@192.168.40.1 tcpdump -i igb2 -U -w - not tcp port 22 | "C:\Program Files\Wireshark\Wireshark.exe" -i - -k

@jsparla - The ideal situation there is that the company selling home automation solutions might work with us to find the best way to integrate tested, supported hardware appliances running pfSense software from Netgate. Many other companies use our appliances as a piece of the overall solution they offer. The SG-1100 and SG-3100 come to mind as highly flexible, supported, affordable solutions for larger projects. We have a partner program that might fit right in with the business model you reference. Feel free to contact sales@netgate.com and have a chat to see how we can help. Thanks!

Something there is different. DNS maybe? Can the Windows device resolve outlook.com? What error do you get when you try to load it? You have any packages running on pfSense? Steve

@demoso said in WIFI calling hiccup over bridge: allowing an untagged LAN on the wireless AP has fixed this issue Normally, when you use VLANs with an AP, it's to use multiple SSIDs. While you could send VLAN frames over WiFi, I really don't see the need to, in that you're unlikely to have something like a phone and computer share the same cable with different subnets.

Usually it's because it can't add that route for some reason. Since there doesn't appear to be a conflicting route there, a permissions error maybe? Steve