@siegmarb said in dpinger not reliable - ping request/replies: no, i did not set the id manually Ok, seeing the same on 2.7.2 (I'm on 25.03-BETA on prod), that's normal then.

@SteveITS the issue of duplicate IP#s is one that I didn't see (or that didn't strike me as odd for some reason, but you would be right). I need to set this aside for a couple of days and maybe pick it up after I get some higher priority issues taken care of. Thx.

@kj32 User error. I found some old notes that included this observation: "Lan gateway should be defined under System | Routing, not interface." Removed the spurious definition under interface, and now it works again.

I am hoping this fairly ancient -5100 appliance holds on. It's been through a lot including several dead cable modems. However, physical intervention has to wait until my next in-person visit. I only have non-technical people on site (as indicated by the hard power off recovery). The site is in an area with buried cable and a high water table which is a recipe for disaster (eats a cable modem every 18 months) and explains the starlink back-up. We use tailscale so remote access is fairly tolerant of CGNAT and our windows DC / local users can phone home and network admin can remote in. When the comcast circuit is down I lose remote admin via the fqdn/public IP which is stressful as I'm reliant on tailscale coming up using starlink. As a first order trouble shooting step I'm stepping up a local VM as a tailscale client to give myself a back door if the netgate box becomes unreachable again and potentially to automatically attempt a pfsense reboot in the event of a sustained loss of connectivity. I will experiment with turning off gateway monitoring after that and watch for physical events. Next time I'm on site I'm going to insert a fiber media converter between the cable modem and the netgate (or it's successor if I can get the budget for it) to remove physical plug events from cable modem reboots and risk of electrical shocks on the wan port.

@netblues And UPnP is also port forward.. just automagic. But as I said, never got it to work behind private IP using STUN. There is a feature request active to get a setting to allow UPnP to accept WAN with private IP though...

If the OP needs remote access or host services, they should be using a VPN like Tailscale, which will traverse any level of NAT, including CGNAT

@laurens-DS said in HA Setup: The problem was I had WAN2 set up but nothing stuck in yet because I don't have a 2nd provider right now That is not the classic HA from the documentation. What you're want to do is HA with Multi-WAN. Have a read through Netgate doc: High Availability Configuration Example with Multi-WAN.

@viragomann Hello, Thank you for your help. I changed the default routing to create an additional static route for this unique IP, in order to replace the subnet route. And for accesses that require it, I create policy-based rules. Have a very good day.

I finally got Ping working in Windows. Had to accept ANY source for Remote Address in Windows Defender Firewall for Private.Public Profile. And I am getting sub ms response times from the Pi to Windows (~0.56ms). So the route seems to be direct without any detours. Traceroute still fails, but that could be the ISP modem/router not allowing it. So, it appears ~75Mb/s is the best I can expect. 5x faster than before!!! Thanks Everyone! P.S. ICMP also needed to be added to the Firewall Rules in pfSense on the WAN interface to allow Pings through

@patient0 Thank you

@ddbnj Awesome!

@drmarian0 Yes, the rule should work. Ensure that the policy routing rule on pfSense is applied. Is it configured for any protocol? If it's TCP only ping will not work. Enable logging, then try to access a public IP and check the log after. Or run a packet capture on OPNsense on the WG interface to verify that the upstream traffic is routed over the VPN.

@MrHedgehog With any luck, this will be fixed in the next release of Plus and CE: Redmine: https://redmine.pfsense.org/issues/16103 Meanwhile, anyone who continues to experience this problem can manually patch /usr/local/bin/ppp-linkdown.

@viragomann said in Multi WAN and multiple gateway issue: The proper rerouting is controlled by the reply-to tag. Did you disable it in System > Advanced > Firewall & NAT or in the rule by any chance? Not disabled. I didn't look closely enough when reviewing the state tables to see if WAN2 was referenced when WAN1 should have been. Hopefully it never happens again, but I have some things to look into if I ever come across this again. Thanks for discussing it with me!

@michmoor Yeah could be broken in many ways. I haven't used it for anything else. Thankfully I got another spare port.

@hillblock The problem in this thread is that the VPN endpoint is not the default gateway. In this case an outbound NAT rule enables you to access the local network. But the NAT has no impact on accessing the web GUI of pfSense, since this traffic doesn't doesn't go out on an interface.

@AlcMat Sniff the traffic to see if the masquerading rule works properly. If it's fine that's all you can do on pfSense. Then there might be something wrong on the Windows machine.

@Gblenn These rules weren't added on both my pfSense box installations, I'm aware what masquerade is and does from working with iptables, however I don't see any masquerade option within pfSense, and definitely no rules were added automatically to help me allievate this situation. I'm not even sure what the automatic rule should look like but I do have a bunch of them on each installation.