@rustydusty1717 Accurate, comprehensive, numbered diagrams always help.

@viragomann
One more question please. VLANs. What is the general concept if I want VLANs to work through PFSENSE? In this case, PFSENSE, as the core of the network, has OVPN and IPSEC clients. Should I want VLAN111 on the OVPN1 client to see VLAN111 on the OVPN2 client, or even more VLAN111 to see on the IPSEC1 client?

Got everything up and working now with the LAN block as virtual IP's.

FYI: For anyone changing the WAN adapter assignment, I found that I needed to go back through the CLI instead of the web browser to reassign all adapters before it would start routing traffic. Initially, I made the change on the adapter in Esxi, but nothing connected to the internet. Then, I created a completely new adapter and assigned it as the WAN interface in the web browser, but still, nothing happened. Eventually, I went through the CLI assignment for just the WAN and LAN, and then traffic started routing again. After that, I was able to reassign and reset the interfaces with the web browser.

@darkcorner said in WAN 1 and 2 Up, but no internet access:

Or leave the two Google DNS without associating them to the Gateways?

Exactly this one.

@rcoleman-netgate said in "Disable gateway monitoring action" NOT working:

You have to monitor an IP address with dual-WAN to make sure the interface is up

I do have IP addresses setted as you can check in the first 3 images.

@rcoleman-netgate said in "Disable gateway monitoring action" NOT working:

Taking it offline from monitoring will treat it as though it is always up and the "member down" setting is made redundant.

That is the configuration I am using now but only because the "disable gateway monitoring action" is not working.

I read all the documentation about multiple wans. But still, the "disable gateway monitoring action" checkmark should be self evident. If you mark that option it should never take any action when monitoring and should never set the interface down. But it does...

@johnpoz

Thanks I will look into the FFR package.

As to them using RIP like I said they are a crappy ISP... They used to use all just regular SurfBoard docsis 3.0 modems and everything was great. But they got sold on this shitty taiwanese Askey hardware and management software (I think because they took over time warner and roadrunner, this is the junk they were using). Well I think I might have gave it away to you which ISP this is, hopefully I don't piss off the ISP overlords and they zap my hardware for being an ungrateful customer LMAO...

@pduk82 well its not the end of the world - double nat is not all that bad, while there are some special apps that might have problems. Generally speaking most users can be behind a double nat, even triple or have seen quadruple and never notice any issues.. More nats in your chain before public IP can be problematic for allowing inbound traffic via port forwards, but still able to do - just have to port forward on the device(s) upstream of your pfsense

@dtnb Simply means the path to your monitor IP or maybe the monitor IP itself is not healthy.

edit: I see the monitor IP is 192.168.1.254 which is your ATT modem in this case. Perhaps a cabling problem? Have you tried swapping the patch cable?

@jegr said in small gateway bug after 23.01 upgrade?:

@jimp Applied the patch yesterday and had to change back all and every changed GW that was saved with lowercase back to uppercase. As manually created GWs can be lowercase, too and Interface names can have that, why not simply make it case insensitive to both work? That way one wouldn't have to switch back and forth between upper or lowercase? Made the whole setup break again :/

That is a much more significant (and likely disruptive!) change than putting the automatic names back the way they should have been.

Manual entries would not have changed and wouldn't have had any issues (upper or lower), only fully dynamic entries were a problem.

Well, I finally got it working. From the online manual I found on the internet, my ISP router is an ONT, not a ONR. Someone pointed out that it being an ONT means that bridge mode was unnecessary. So, first thing I did was plug Pfsense in without bridge mode.
But that was not the end of it because I could ping 8.8.8.8 but was still unable to connect to the internet. Diving into the forums led me to this, which resolved the problem.
https://forum.netgate.com/topic/106121/fresh-install-does-not-give-internet-access-resolved?_=1679934258140

Solved!

I made the rookie mistake of using a new OpenVPN server, instead of first getting things working with the old OpenVPN server.

On the new OpenVPN server, I forgot to set ip forwarding on. It is set off by default. To enable IP forwarding, you need to uncomment the line net.ipv4.ip_forward on the /etc/sysctl.conf configuration file and set its value to 1. This is for Rocky 9.

On pfSense, I set the OpenVPN server as a gateway, and set up static routes for the two networks (192.168.1.0/24 and 10.9.0.0/24) to the new gateway.

It works perfectly now.

Thanks to all who replied!

After further testing I have determined that the VPN tunnel did not fail.

I created a new tunnel to a different location.

Connected the ipsec tunnel between the two locations and did a test ping to the pfsense server private ip address, (192.168.10.3) it works.
Connected to the another host on the VPC network at DO and set its default gateway to 192.168.10.3 and able to ping it from the remote host of 192.168.0.2. The constant ping has been running for 2 hours now.

But I did determine that when the initial site-to-site tunnel was connected, I lost communications to the public ip address of the pfsense host at DO from my local computer. (not part of the current VPN tunnel) And from the local VPN site, I cannot open the private ip address of the pfsense host through the vpn tunnel. https://192.168.10.3. But I can ping the host of 192.168.10.3

I have a setting wrong someplace. Any suggestions?

I had this same issue and what worked for me is creating a floating rule on the downstream PfSense to allow WAN to LAN connections. YMMW.