@stephenw10 cheers for the suggestion. I haven't tried that! but can do next time it dies and see what happens.

@stephenw10 said in Gigabit internet PPPoE and pfSense:

@riahc8 said in Gigabit internet PPPoE and pfSense:

could I install pfSense there to rule out any issues????

Yes, it's a good test if you can do it.

Yeah, I havent used it and/or turned it on in a while.

Ill install pfsense on it when I can and see how it performs there.

@stephenw10 said in Upgrade to 22.05 has killed my pppoe WAN:

You can fetch it and install it:
So fetch it in advance and install it manually if required.

Thank you, @stephenw10 ! That saved my day. The upgrade from 22.01 to 22.05 went wrong again the same way. I transferred the mpd then to the machine, disabled and re-enabled the WAN IF and I had internet connectivity. Running the upgrade option (13) via shell then again and it updated the remaining stuff. It's in final startup now and I hope all will work ;-)

The states might be closing quickly. You would need to be trying to open a connection to the server whilst checking the states.

Do you see any blocked traffic in the firewall log also?
If there is another route to the server and that works is the server using pfSense as it's default route? If not you probably have some asymmetric routing.

Steve

That is the default setting in pfSense.
There is no SIP ALG unless you install the siproxd package, which you shouldn't.
All ports are open outbound for any devices on the LAN.

So unless you have added firewall rules to block traffic it should be allowed. However I would check the firewall log when it fails. I would also check Diag > States to see what states are open to/from the ATA191 IP and what changes after you reboot and it starts working again.

The only thing that pfSense does differently to many (most?) SOHO devices is to set a random source port on outbound connections. Some services, including VoIP, object to this (VoIP and NAT are mortal enemies! 😉 ) requiring a static source port rule to be set:
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html#disable-source-port-rewriting

Steve

Shouldn't make much difference.

What latency are you seeing across the tunnel? What hardware are you using? What speed do you actually see outside the tunnel?

Use the WAN as source. The last thing you want is a VPN connecting out across another VPN, either way around.

Steve

@Cool_Corona Please contribute constructively. Thanks.

@stephenw10 said in OpenVPN + WireGuard breaking DNS resolver.:

No worries. Let me know if that helps. There easily be more interactions happening there based on the connection timing.

Steve

It works !!

I removed the monitoring IP`s on both gateways, and i enabled "Do not create rules when gateway is down" in System / Advanced / Miscellaneous.

After reboot, both WireGuard and OpenVPN clients connected as usual and all subnets are going through their designated gateways.

Once again, thank you @stephenw10 !!!

Probably a DNS issue. The error the client is showing is probably saying exactly that....

@sdok looks like ntopng was the problem. just posting the resolution in case anyone else has the issue. thx for the replies.

@johnpoz
No budget for me to get brand new these stuffs😊
My most equipments are used, except for the T630. It's getting harder and harder to get a cisco in my area. So I'm considering change the sg500 with a ICX7150-C12P(for l3 switching and poe) and a C2960L-24TQ(for access).
But don't know the compatibility between Ruckus and Cisco

@jarhead
My mistake, confused vlan with lan during setup.

I assume the modem MAC disappears from the ARP table too?

If you run a pcap on em0 when it fails do you see any incoming traffic at all?

There's a lot of history here. Some of which might be relevant.

That additional interface shows as down in the first screenshot so how is it configured in VBox?

If a connected client receives a DHCP lease though it must be connected correctly. In which case it can only really be firewall rules.

Steve

There's no easy way to that. There's nothing built in like easyrule for NAT.
Anything is possible with code though. 😉

Steve

This a known and long-standing issue in VMWare. Adding 4 or more VMXnet NICs re-orders the the way the NICs are presented to the guest.
Re-assigning the interfaces to the new order is really all you can do. Unless you want to map then NICs to the PCI bus manually in VMWare.

Steve

Yeah, that's exactly what those Range Extenders do; hide all the connected clients behind their own MAC address. The first time I saw that I could hardly believe it was real. It's ugly as hell and best avoided if at all possible!

Steve

@jsingh04 said in Static wan IP stops working after a power cycle:

it shows a name resolution error

Then you have a DNS problem.
When you set the WAN as DHCP it probably pulls some external DNS servers that the firewall itself can use if it's own DNS resolver is not working.
When you look at you system log you will note that initially the date/time is wrong. The boot log shows there is an RTC present but it seems to be incorrect. Probably the battery needs replacing.

When you boot it with a static IP set after a power cycle the clock will be wrong and that leads to a scenario where Unbound fails to start because it's cert is invalid or it see results as invalid because DNSsec is enabled (by default). That means ntpd cannot resolve any external servers and the time cannot be updated.

So do one (or more) of:
Fix the RTC battery.
Add at least one external DNS server when you use a static WAN.
Disable DNSSec in Unbound.
Add a local NTP server that can be reached by IP address.

Steve

@bmeeks rgr that and thank you for the info. I did go ahead with the full reinstall just to be sure, but being able to reset is good option and thank you for the reply.