Almost impossible to say without seeing the routing table. You might have something tied to a MAC address maybe? The fact inbound connections work and outbound don't can really only be a firewall rule on the internal interface, a routing issue or no outbound NAT rule for internal clients. Hard to say why that would be any different between the two instances. Steve

Ah, Ok. Yeah Client ID is not required and is only shown as a column if any clients are sending it. You can probably remove it from those static mappings. Steve

@Gertjan so i have internet working throught the vpn but am i supposed to see on my local network when i google "whats my ip" should bsee my ISP address or should i be seeing the 192.168.110.5 for the landon Openvpn account.. and when i run the dnsleaktest same ip as the ISP and cloudfare is the dns and using cell internet doesnt point to the 192.168.110.x could you happen to send me to a document or video that shows how to set it up. i read 1 article guy didnt know how he got it working.. but if there is a document or video be good or do i need to start a new topic..

@JKnott i know it took a while, but i didnt have another client that i could hook over lan on it, so i bought a usb-to-rj45 connector. with that said im getting similiar results. i go into the console and start to asign interface, but then back out of the command using ctl c. I then connected for a minute or 2. i must have some conflicting setting in my GUI but have no idea where to begin. i may reset to factory and see if it works without reloading my config.

@heper That did it. Tnx.

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"