I was able to find the solution! Because I was running a VM of ESXi and running pfSense within that VM, I had to switch the LAN and WAN interfaces as-well as augment the default IP of the LAN by 1 (192.168.1.2) because 192.168.1.1 was being used by VMware. All of these configurations were done within the pfSense console provided by the web interface from my virtual ESXi. Once I switched the interfaces and IP, I was able to ping and access the web interface of a pfSense VM loaded within an ESXi VM!

@pctrailrunner https://www.youtube.com/watch?v=g1lVIqEXk5g

Unfortunately, double NAT remains until you can connect to your ISP with PPPOE and get public IP on the WAN interface... What you can see on the mainboard tab with this little app? https://www.cpuid.com/softwares/cpu-z.html Packet Capture: Sure, if you could see a set of log data, we could move forward, but it's also important what hardware we're struggling with right now. BTW: Have you cloned your old ASUS WAN MAC address on pfSense (MAC spoofing)? If I remember correctly you said in the past that ASUS works perfectly, it worked in this setup

@jimp your right i need to change "date". then i was able to flash to WG BIOS 1.3, does someone here have a 1.2 ?

The extra rules used by 2.4.5 use labels like $NVR, $PFSense, $Wall_e. These are not pfSense itself. Reset your pfSense to default, make 'pppoe' work (and stop there) and these labels will be gone. Looks like these rules are part of NAT (?) rules on the pppoe interface that didn't exists when you were using 2.4.4. edit : just in case : NATting, of course, should not be used to access things like pfSense GUI or a NVR. Use OpenVPN server for a secured connection. Then you can access all your local devices without any NATting.

Rules are evaluated top down, first rule to trigger wins - no other rules are evaluated. https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-processing-order.html

Thanks a lot, i'll change it. Update 2020-05-22: After the address change there were no further problems and updating to version 2.5.0-20200522 worked seamlessly.

Weird, My system update was set to Previous Stable Version - I don't recall setting it to that otherwise how was i offered 2.4.5? Either way - i've changed it to Latest Stable version and its now ok on the Dashboard. Many Thanks for the pointer in the right direction.

Gave you a hand with WHAT... You have not provided ANYTHING TO WORK WITH.. Oh you have another thread where you actually posted a pic, and so you are using a pppoe connection... INFO!!

@viragomann said in WAN_PPPOE gateway down but working..: Go to Diagnostics > Traceroute, enter google.com at Hostname and press Traceroute. You will get a list of IPs. The first in the list is your gateway. So copy the next one, open Diagnostics > Ping, paste it at Hostname and hit Ping. If you get a response you can use this one, if not pick the next. Awesome, that's cool Thankyou for your help , really appreciate it.

@davidh1234 It looks like my copy/paste format got all wrong.

@jmorfali Do the webservers use pfSense as their default route? If not then the 'transparent' option is out the window.. There are basically 3 options then to achieve it: TransparentClientIP (possible for all TCP protocols, but does require the webservers default-route and reply traffic back through pfSense..) Seems your environment doesn't currently meet these requirements.. HTTP-forward-for-header (requires that haproxy is operating in http mode so it can insert the http-header, also requires to configure the webserver to use this header for its logging and other actions inside the web application..) Proxy-Protocol (can be used with all TCP protocols but does require that the target server is configured to understand this protocol..) https://www.haproxy.com/blog/haproxy/proxy-protocol/ not a lot of 'server applications' are ready to receive this but some can..

@jludrosky said in New install of 2.4.5 no bookable image: Also the check sum is diffrent before I extract it. Check sum from site fda93684669ad0b2b9e314a53d5c7272076484a6b714d60d5e06f14e1c7ce049 Check sum before extractrion FDA93684669AD0B2B9E314A53D5C7272076484A6B714D60D5E06F14E1C7CE049 Check sum after extraction FB1D253F9C594A7E32418CF43E4B56CF17976CE4FDB6061FDAE559B1BD15DF11 The posted checksum is for the compressed gzip archive. So your "before extraction" value is what you would check to validate the download was not corrupted on your end. After you extract the ISO (or USB memstick image) the checksum will be different and not valid for "validating" the downloaded ISO. The image will be a FreeBSD-11.3-STABLE operating system. The 2.5.0 DEVEL snapshots are FreeBSD-12.1-STABLE. Don't know if that might matter to whatever device you are trying to "mount" the image on. The preferred method these days is to create a USB image using the "memstick" download option. Of course a conventional ISO should work fine once burned to a CD using the proper tool. Not really sure what your issue could be. Lots of folks have used the installers for pfSense Community Edition recently. I assume you are following the instructions as posted here: https://docs.netgate.com/reference/create-flash-media.html#Rufus? You might also want to peruse through this thread from a few months ago: https://forum.netgate.com/topic/141197/can-t-create-uefi-bootable-usb-stick.

I had pulled the other NIC out trying to diagnose. This is just a test computer for now. If I need a better NIC, I'll install :)

hi, yes I set 8.8.8.8, no luck

Thanks very much for the suggestion.

Workaround is to kill the squidGuard post install process, the installation of remaining packages will the complete. I then rebooted and manually reinstalled just the squidGuard package. There seems to be a bug that was reproducible at least on my end.