@Bob-Dig thanks for your feedback again!

Yeah, I think they are assigned properly, unless I'm missing something here and PPPoE actually requires a different assignment.

assigments.png

gateways.png

Thank you!

@Djkáťo

The one and only question that answers your question while answering me : do you have a working Internet connection ?
If yes, then nearly all is fine, and you can stop looking, as you've already mentioned what your current situation is : its doesn't break your internet access if your WAN IP is a RFC1918.
But you can probably forget about NATting so you can make internal (on the pfSense LANs) devices accessible from the Internet, as you have no access to the ISP equipment to do so.

If your "TP-Link Archer VR300" is truly working as a modem, its just converting POTS VDL signals to "Ethernet" signals and it doesn't do routing , firewalling etc. Its not the "TP-Link Archer VR300" that has a WAN, and a DHCP server that gives you the "10.101.37.22" pfSense WAN IP : this "10.101.37.22" comes from way up, somewhere from the ISP.

Why they do so ? There is the classic $$$ rule : they have no more free routable IPs left as IPv4 free available stock has been sold out meany year ago, and what's left has a huge price tag. Its seen before ; you want a real routable IPv4 ? You $$$ or €€€.

Ok, have a look into the DOCSIS Telemetry.

I was hell if my ISP rollout the OFDMA to the upstream some years ago. And your problem looks similar.
Idle was nice, but if you use the bandwidth, the error rat grows and grows and with it the retransmission and the latency explode.
It takes month and 2-3 construction sites to get a nice stable connection back.
Have a look into it fist.

Thank you so much for providing this information. Ever since Xfinity did their infrastructure upgrade in my area I would have intermittent connectivity with one of my WAN's. Currently, I am running two WANS (both Xfinity) and have them in a load balance configuration. When I initially set this up in Pfsense everything was working fine. After the Xfinity upgrade the non-default WAN would intermittently lose connectivity and show as 100% packet loss. The weird thing about this one it would only drop the non-default gateway. The default gateway was always up. So if I swapped the default, the packet loss would also follow the other non-default gateway. So I knew this wasn't a hardware problem, For the past 4 months I have been trying numerous troubleshooting steps including a complete reconfigure of my pfsense setup from scratch and nothing worked, at least not until I added 'supersede dhcp-server-identifier 255.255.255.255' under "Option Modifiers"

Thanks again, this saved my sanity. :)

@bmeeks

4.1.6_11 sorry I had a mix up.

I do not know if this has anything to do with the intermittent passlist block issue. I noticed this error shortly after the above screen shots. Thanks for all you do and also for sharing the code above.

Fatal error: Uncaught TypeError: fgetcsv(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/snort/snort_alerts.php:858 Stack trace: #0 /usr/local/www/snort/snort_alerts.php(858): fgetcsv(false, 1000, ',', '"') #1 {main} thrown in /usr/local/www/snort/snort_alerts.php on line 858 PHP ERROR: Type: 1, File: /usr/local/www/snort/snort_alerts.php, Line: 858, Message: Uncaught TypeError: fgetcsv(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/snort/snort_alerts.php:858 Stack trace: #0 /usr/local/www/snort/snort_alerts.php(858): fgetcsv(false, 1000, ',', '"') #1 {main} thrown

Screenshot 2023-10-06 at 5.49.45 PM.png

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

Similar problem in CE2.7.2 in AGO 2024

@stephenw10 Thanks for reply. I was also informed on redline last night.

@aiden21c Good! I still think that some good came out of this whole situation, though.

For one, even if your current setup works well, the ideal setup for your whole company network is still with VLANs The order of the firewall rules needs to be held in mind (PfSense processes firewall packet rules from top to bottom):
1c9cfaf5-771e-4d8c-959e-e798596807bd-image.png
Rule 3 catches all traffic filtered by rules 4, 5, 6. It needs to be last. Rules 5 and 6 have destination address "Any" instead of "LAN Address". A way that helps (me personally) to keep fw rules tidy is to add 4 separators, the top one named "GENERAL BLOCK" (for entire protocols, for example, no need to allow GRE, ESP, AH, OSFP... on a LAN with interconnected servers if there is no explicit need), a second separator named "INCOMING", a third separator named "LOCAL TO FW" and a fourth one named "OUTGOING". I also add separators named "PASS" and "BLOCK", with that order, under each main separator. Even if no further network changes seem necessary, it is best to avoid NAT. In the future, in order to reduce latencies or enable certain UDP services that cannot be NATed, you can check if the Cisco Router can do PPPoE passthrough for PfSense. Because PPPoE is a separate interface in PfSense, you can have both a PfSense-to-Cisco connection (OFFICE - 192.168.20.40/24, not as a Gateway) and a PPPoE adapter as a direct PfSense Gateway (because PPPoE is a Layer 2 protocol, doesn't use IPs, that is why its Point-To-Point, so it doesn't interfere with the 192.168.20.0/24 subnet at all) with a public IPv4 for PfSense. At some point, instead of having separate rules for each gateway and traffic type, you might want to implement Multi-WAN Load Balancing and Traffic Shaping to control which traffic type uses what Gateway. It is best to set static IPs for LAN through the DHCP server (without a dynamic address pool) and set your private IPs as Static Mappings. That way, you can use Host Overrides on Unbound, which would allow you to use hostnames (and no IPs) in your setups, and avoid unnecessary config nightmares in case, say, you want to put everything in Docker. You can just change the IPs in the Static Mappings of PfSense Unbound, add a BIND container to Docker (just to handle the inter-container IPs using the same hostnames) and be done with it.

@aiden21c it’s always the last place you look…

@jimp Thanks for confirming, I had missed the redmine ticket.

so upon disabling and re enabling the WAN interface this is when i see the issue occur. the only action that can be taken it seems is to manually select the gateway removing it off the automatic option. restarting the gateway service nor reboot changes its behaviour.

Running on 2.6.0-RELEASE (amd64) wonder if anyone else is getting the same issue?

@lolo54000 said in Ipv6 configured but unable to ping internet:

In my ovh account i have 6 physical server and each have it's own ipv4 and it's own ipv6 /64 ipv6

To have a router in front, you would need:

an IPv6 for the router WAN an IPv4 for the router WAN OVH to route your other IP addresses to those IPs your servers to use your router LAN IPv4/IPv6 as their gateway

It sounds like they are simply not set up to handle a router, like you're asking for.

Re: PFsense random loss of WAN gateway

I just wanted to add my thanks!

I have a Telia Fiber connection and it would lose WAN every six hours. Turns out that the Telia DHCP server only allows a limited number of renewals after which it demands a broadcast again.

The above option to always broadcast works fine.

It took me several month to find this solution! Thanks again!

@stephenw10 I guess there is VLAN configured because I didn't need to set it on the pfsense

And logins to other more remote sites will be encrypted with https or similar.

@bob-dig
yes destination is internet.

So this is why I get the NAT3 on the ps4 right?
in short, because the vlan's gateway is not exposed to internet but is behind the wan.. right?

sorry what you mean with If the destination is at your place then number 3
another vlan or the lan?

thanks again

@joe90

If it is assigning an address from with your prefix, then that address will start with your /56 prefix.

I don't have any experience with IPv6 on PPPoE or with OpenWRT, so I don't know what else to check.

However, you don't need a WAN GUA. If you want to access pfSense from elsewhere, you can use the LAN interface address.

@g-luke said in Configurazione OpenFiber WAN - PPPoE VLAN:

@wifi75 non mancava nulla.
Avevo fatto tutto esattamente come hai suggerito tu, ma non c'era login.
Ho chiamato il provider il quale ha inizialmente detto che poteva essere un problema del mio router, così mi sono procurato un altro router ma neanche con questo c'era login.
Di conseguenza hanno aperto un ticket con OpenFiber, e alla fine è venuto fuori che quando hanno fatto l'allacciamento si sono dimenticati di attivare qualcosa, per cui non c'era possibilità di connettersi.
Io avevo dato per scontato che fosse un problema di configurazione perché dopo che OpenFiber ha fatto l'allacciamento ho chiesto espressamente se la linea dovesse essere attivata dal provider, ma mi hanno assicurato che "potevo già navigare!"

Che provider?

If you're unable to reach the pfSense webgui that sounds like either an issue LAN side or some routing conflict, like maybe your modem lost sync and came up with an IP the same as the LAN subnet?

Did you try connecting out from the console directly?

That's what I would do, determine exactly what is failed so:

Check the interface addresses, at the command line: ifconfig -a

Try to ping out by IP address and by fqdn.

Check the routing table: netstat -rn

Steve