WAN failover is described here: https://docs.netgate.com/pfsense/en/latest/book/multiwan/index.html In addition to using policy routing you can now also set the system default gateway to a failover group which will also route traffic from the firewall itself. You can, and probably should, have both WANs set as DHCP. It may be showing as unknown if the service is not started or there is a subnet conflict perhaps. More likely the latter. You IoT/Guest AP should be in a different subnet to the LAN. That interface should be separate. The pfSense interface IP would commonly be .1 and the AP IP should be either statically set outside the dhcp range on that interface or set via a static dhcp mapping so you always know where to access it. IPv6 should probably be set to track PPPoE unless you have a static IPv6 address. To be able to have guest and regular users connected to either AP you want to set them up with multiple SSIDs on different VLANs and separate the traffic that way. Both APs should connect back to pfSense on the same port carrying all VLANs. VLANs have nothing to do with connecting between subnets, each VLAN would be a separate subnet. Traffic from the IoT/Guest subnet will be able to reach resources on LAN as long as there are firewall rules allowing it. Conversely you should have firewall rules blocking access to the LAN for most guest clients. Multicast/broadcast services, like Chromecast, are a different matter. They are not intended to be used across subnets and additional measures are required (igmpproxy/pimd). Anything that should be in the same subnet should be on the switch. Interfaces on the SG-5100 are not switch ports and though they can be bridged to act like switch ports moving traffic between them requires valuable CPU cycles they could be used elsewhere. The lag introduced going through a switch is negligible. IP cameras would normally be considered an IoT device. Commonly found with known firmware vulnerabilities and no updates from the manufacturer. That would denote they are put on a separate subnet with very limited access to anything else. However they also generally generate a lot of traffic which will all have to be routed by pfSense if they are separated from the NAS like that. The decision is yours! You can apply a basic priority based shaper to prioritise traffic from the xbox IP. It will need a static dhcp mapping to do so. However I would not do that unless you are actually seeing latency issues. Adding traffic shaping often introduces more problems that is solves. Steve

@thompsonm Screenshots of your rules on the two interfaces?

Unless you do dynamic assigned vlans, yes you assign vlan X to ssidX and vlan Y to ssidY be it they run on 2.4 or 5 band or both doesn't matter.

@stephenw10 said in Problem with pppoe over vlan: Hmm, so even though you no longer have vlan7 assigned it still gets rebuilt when config changes are made? YES! (I checked a few times on both machines)

Nice.

@skybri100 Thank you very much and greetings.

Bingo! I reset it while connected and started getting console output of the boot sequence. It was getting stuck on "Starting DNS Resolver". Quick google lead me to a Reddit post below. Basically delete this "/var/unbound/pfb_dnsbl.conf", recreate the file, and restart. Back in business! You help was very much appreciated John! Thanks, Moon https://www.reddit.com/r/PFSENSE/comments/89gt37/stuck_on_starting_dns_resolver_on_reboot/

Then make sire rules in place at site 2 allowing the traffic from the tunnel subnet the client is in. If the client is not redirecting all traffic over the VPN then they will need to be passed a route to the site 2 subnet via the VPN. Add it as a local network in the remote access server at site 1. Steve

@stephenw10 Great ! Its as I expected, Thank you very much for your answers ! Farisse

The proxy musy be listening on the OpenVPN interface since that's where the traffic arrives. You should be able to put the proxy at either end but I would probably put it at A since that's where traffic is arriving. I'm not sure how the proxy would reply to traffic at B either. Importantly you must have the OpenVPN interface assigned at B and make sure the rules passing the traffic are on the assigned interface and not on the OpenVPN tab. Without that you will not get reply-to tags on the states and the replies from the server (or proxy) will just go out the WAN rather than back over the VPN. That creates an asymmetric route and traffic will be blocked. Steve

Yeah with 5Mbps upload you can saturate the connection pretty easily. However it's also much easier to shape upload than down since we can control exactly what leaves the interface. I would expect to see good results from fq-codel here. Steve

The comment that its easier to fail to untagged vs tagged is a valid statement.. And if your worried about vlan hopping ok... But unless you were in some DOD facility, or had to use known bad switches that drop traffic from tagged to untagged.. It not a "requirement"

I see. I found that one. But thought it odd i couldn't find it on the dashboard, can show individual temps, so why not usage. Was sure i was just looking in the wrong places.

@bkhiatt One thing to check is the DHCP lease, to see if it's being renewed, but given your description that doesn't sound like the issue. Can you ping the gateway when the connection fails?

@guardian said in Certificate Question: Sorry, I don't understand this [image: 1598516212016-9d2889ce-108a-4052-b3f4-0fe0f9abdd88-image.png] One of these reset the GUI access to http. The manual will tell you more. @guardian said in Certificate Question: IIUC this is only if the last configuration was http It must be the last setting change, the one you can cancel. If you change from http to https, and you lose access because https won't work for you, you loose contact with the GUI. Rephrase that : you loose the ability to make changes ^^

I'm US timezone - CST..

@EagleGC You have to have the Procurve switch plugged into the SG-1100 LAN network, which it looks like it already is. Then, the Nest wifi router should be in access point mode, then plugged into a switch port on the Procurve switch. This process will put them all on the same notwork. The Procurve shouldn't "hand out" any IP addresses, you should set it up to NOT offer up IP addresses. Unless, you've got a special reason to do that. Jeff