@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

Doh! Test Port indeed.