Slowness on save with those units would have to be one of two things: 1. DNS, which you've found already or 2. AutoConfigBackup pushing a backup to the servers on save and taking a few extra moments to do so DNS is the usual culprit, if you have ACB though it can vary a bit depending on how busy your link is, how busy the server is, any issues in between, etc. (If you register those boxes you should have access to ACB if you haven't done so already)

Looks like you tried a few times.  ;D You can safely get rid of pppoe 0-4 if everything is working.  Most likely they are just duplicates from when you were setting things up.

Saw your post over on that other project's forum. PPPoE multi-WAN with the same gateway IP has worked in pfSense for quite some time, that only works in OPNsense because we fixed it years back (the only thing they've actually accomplished functionality-wise is breaking things that worked in the code they forked). I'm guessing you found some really old references that are no longer applicable. Maybe you have an unusual edge case, which if that's the case, please start a new thread describing what you're doing. Multiple PPPoE with the same gateway most definitely works though. With pfSense, when you boot up, your rules are actually loaded correctly, unlike some other projects. And our reply-to actually functions, unlike some others (that bug should really be labeled as "multi-WAN is non-functional for all inbound traffic"). Multi-WAN IPsec works, unlike some others. I could go on. Suffice it to say, you're in for a world of hurt if you continue down that path. They've broken a lot of key multi-WAN things where you won't have those issues here.

ifconfig on the PPPoE interface won't do anything there. You can run this: /usr/local/sbin/pfSctl -c 'interface reload wan' >/dev/null 2>&1 || exit 1

LAN up manual 192.168.1.1 DMZ up manual 192.168.2.1 PIAVPN up I have deleted the 1:1 interface for 192.168.1.1 to 192.168.2.1 but I can still access 192.168.1.1 from the 192.168.2.x subnet.  Why would that be?

I run DHCP, but it's static entries.

@cmb: If something went really crazy requesting BOOTP or DHCP leases, it could create a really large DHCP leases file, which could exhaust the space in /var/. Can't recall hearing of that happening with IPv4 but it's possible. No printers on the network, just a couple Win7 boxes, and an ARM box running a linux variant at the time. I'm in the process of getting more data logging setup so if it occurs again I might be able to provide more info, but one thing I saw in pfsense was alot of references to nics changing from their ip address to 0.0.0.0.

Are you using some proxy (squid?) on pfsense where your trying to do ssl bump so all https sites get a cert from pfsense.. Does this only happen when trying to access your exchange or does it happen on all https connections? I assume when you say windows based vpn you mean the vpn client running on windows OS - the openvpn client?

"Or using a non-persistent disk." Possible that the VM restarted and if using a non-persistent disk type in the VM would go back to initial stuff.  Did the VM show a restart.. I can not fathom how running and all of sudden just loose all config and data on the disk, etc.

It looks good to me and I'm also using the same resolver on my OpenBSD router where twitter.com displays fine: leiter% drill -T twitter.com com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. twitter.com. 172800 IN NS ns1.p34.dynect.net. twitter.com. 172800 IN NS ns2.p34.dynect.net. twitter.com. 172800 IN NS ns3.p34.dynect.net. twitter.com. 172800 IN NS ns4.p34.dynect.net. twitter.com. 30 IN A 185.45.5.32 twitter.com. 30 IN A 185.45.5.43 twitter.com. 86400 IN NS ns1.p34.dynect.net. twitter.com. 86400 IN NS ns3.p34.dynect.net. twitter.com. 86400 IN NS ns2.p34.dynect.net. twitter.com. 86400 IN NS ns4.p34.dynect.net.

Just checking : what is your WAN IP ? Or, saying the same thing differently: is there a router in front of pfSEnse, or pfSense deals with an "Internet IP" (is != LAN IP).

The finalised version of this was committed a few days ago. @rowell - can you try https://github.com/pfsense/pfsense/blob/RELENG_2_2/usr/local/www/interfaces_ppps_edit.php (that is the version to be released in 2.2.4) Does that fix the issue?

Thanks!!! I will be contacting Dyn.com

I have allowed my pfsense box to be pinged, so as long as they don't somehow look for their SPECIFIC router, I should be good. And if they are calling you otherwise they perhaps where monitoring the MAC address of their router. Perhaps you are able to change the MAC address from their WAN interface to your WAN interface.

You could set it up with just the one LAN interface as a pure Squid3/squidGuard/ClamAV web proxy.  No need for NAT.  Squid would have to be in explicit mode, so all your clients would have to be configured to use the proxy or you would have to setup WPAD for proxy auto-detection by your clients.

The last time I saw this, the person incorrectly configured the forwarder on his DC.  By chance did you manually configure the forwarder in on your DC?