Set Debug in the DHCP6 Client Configuration on WAN as well, then check the logs (main system log, routing log, etc) to see what shows up.

@eidolontubes Example below...

(LAN 192.168.1.0)---(Netgate OpenVPN Client TAP VPN IP 10.10.10.2)---Internet---(Netgate OpenVPN Server TAP VPN IP 10.10.10.1)---(Remote LAN 192.168.10.0 - DHCP Server 192.168.10.5)

Leave "IPv4 Remote network(s)" blank in your OpenVPN config. Use system routing instead.

On VPN Client side
Create Gateway 10.10.10.1
Create Route 192.168.10.0 -> 10.10.10.1
DHCP Relay 192.168.10.5

On VPN Server side
Create Gateway 10.10.10.2
Create Route 192.168.1.0 -> 10.10.10.2

Yes, it looks like that fix didn't make it into the last build before we stopped snapshots to move to FreeBSD 12.

https://redmine.pfsense.org/issues/9316

Applying the commit on that ticker via the System Patches package fixes it though:
e0b32eb9e6b040fd14025b5c32644959ba67250e

Steve

@doktornotor This worked for me too! Thank you!

Hey i use it also it works, but i have the errors above, if i remove LCDProc from pfsense they disappear, when i install LCDproc back they again appear but LCDProc works ! can you put out a screenshot with your settings please ? maybe there needs to be something setup that i did not

Ah OK, that makes sense.

Thanks for the reply.

@ozlecz I am getting 300dl/30ul using a 5 way round robin PIA VPN outgoing setup. Using PIA's high encryption I get 150dl/30ul which may be a limitation on their end.

On a system effected by this it should normally boot correctly after an upgrade but with no console. The webgui should still be accessible though.

If for some reason it is not interrupting the boot to reach the loader prompt and doing:

set kern.vty=sc boot

Should allow it to boot with a working console to correct whatever other problem exists.

Steve

i have same issue anybody find the solution @dcol @jimp @barakah @Kain

Looks like that is due to squid moving versions, on 2.4.5 the package uses the www/squid3 port so it didn't pick up the settings in our config that were for www/squid. I pushed a fix, squid will get rebuilt with the new settings.

Hello,
Since you can't share bandwidth across multiple interfaces, you are left with three options.
Give each LAN segment a fixed amount of bandwidth for each of the WANs. No bandwidth shared, free bandwidth from one interface cannot be used by the others
Configure each LAN segment like the above multi-wan-single-lan shaping, but you won't gain a whole lot
Don't do any LAN shaping.
1 and 2 will have the same queue setups, just the amount of bandwidth assigned to the queues will be different.
Best,
Arso

We're focused on 2.4.4-p1 and nothing else right now. Hoping to have it out very soon.

Great news! Thanks for testing

Still working on it. Waiting on the latest snapshot to come out today to test the recovery image and then to test upgrades as well. Hopefully should be OK today.

Oh ok, thanks.

@rschell said in No local user authentication on 10-20 snap for GUI:

the change set for issue #9051 appears to have caused this. If the router is relying on local authentication, the changes block checking the local database.

Thank you for pointing this out, I have reverted the files to their old contents per the diffs and all is well.

Diffs here:
https://redmine.pfsense.org/projects/pfsense/repository/revisions/fe1afbb7549907e0d1cdfbf85d5f36d075a6a916/diff/src/etc/inc/auth.inc
https://redmine.pfsense.org/projects/pfsense/repository/revisions/fe1afbb7549907e0d1cdfbf85d5f36d075a6a916/diff/src/etc/inc/priv.inc