@ttblum see https://forum.netgate.com/topic/160694/frr-7-3-7-5-bgp-not-announcing-routes

@genuine said in "sendto error: 65" after 2.5.0: Try to change the gateway monitoring ip to a dns of your isp see if thats better or take a public one example 4.2.2.1 I added my gw monitoring ip to Rejected Leases => [image: 1614903973338-9efd731f-0e6c-48e3-b46e-95efd937fb48-resized.jpeg] And that error was gone. Trying to understand which is a better solution? Thx for the reply

@alefe thank you for your offer, but I don't want to waste to much of your time trying to schedule a remote session. Let me try explain what is the problem on home lab example: We have following gateways config with default gateway set to failover group preferring GW1 [image: 1614895364891-be01e3f0-9d6c-49a0-ad07-52bd239ca1f6-image.png] [image: 1614895400296-d0ab0bb3-ffef-42af-bbd7-678094b0e21b-image.png] And LAN rules are set to use only GW1 172.16.0.1/24 only, do not use failover. [image: 1614895990189-1d84f43e-ca38-4e1b-bc89-272b36ec45dd-image.png] and when you have GW1 down [image: 1614896373622-40b81554-6f93-42b5-936b-a27aa3a2be3b-image.png] FW makes a failover to WAN2 regardless of the rules setting to use only GW1 [image: 1614896513050-7e980426-2fb3-4609-85a4-c77e96dd657c-image.png] Only if I set default GW to something different than GW group like automatic or ether GW [image: 1614896653818-10ea2306-6833-429b-b52e-65a91ea0a868-image.png] Then the GW settings on FW rules are followed/respected: [image: 1614896992960-dd811aca-a9ee-412d-8d42-a70493c06ffe-image.png] Hope I explained my query clearer now. And my question is: Is this is expected behaviour? Best regards, Piotr Marchewka

@griffo said in Using same gateway monitor IP not allowed: But I don't want to pick some random service provider gateway IP OK.. I was thinking of your own provider (ISP), it's not random... DNS servers are not designed and used to send ICMP responses depending on their workload, the responses received also differ, so they do not provide relevant information so let’s stick with this first ISP GW as a good solution BTW: the forum is full of discussions on this theme the end is always that the DNS server(s) is not a monitor IP alternative

@gwaitsi after further reading, it seems the pfsense device would gain by having all nics with either network and using the isp provided fritz box as a switch in between. They have configured one of the switch ports as a pppoe wan connection. and the other 3 ports to the lan side. So I am also left with a bypass option. I have more of a performance drop from the J1900 than from the fritzbox which in any case.

Update 3.3.2021: I noticed that if I will manually do DHCP release and DHCP renew on Pfsense , the traffic will immediately start to work, even though the IP stays the same. Running on 2.5 version of Pfsense.

@why at the end is more or less the same setup that I did. I started from nguvu guide and adapt to dual-wan failover. Until now (finger cross) all tests I did the wan switch always worked (but I had to remove the persist-tun option otherwise the vpn connections didn't change wan). Two things: now the VPN gateways monitored IPs are the gateways itself and I have a different tier numbering: wan failover: wan1 is tier 1 and wan2 is tier 2 vpn balancing: all in tier 1

@jimp thank you, I wasn't able to find that. so I will wait for 2.5.0-p1

@gwaitsi oh man.....i deleted the cable interface and gateway, added it back so the order in the list shows Fibre first, Cable second.......and still after boot it keeps putting the little default globe on the cable connection

I'm an idiot. Use VTI instead of a tunnel and it works fine. Days wasted.

@why thanks, it seems there wasn't/isn't anything fundamentally wrong with what I am doing then. It was working, but i started having a problem with smtp clients on windows / linux which is why I was asking. But it seems to be a problem with setting the default route of the rule to a gateway group. I just don't understand why it has started over the last week. https://forum.netgate.com/topic/161496/smtp-fails-over-gateway-wan-or-vpn

@paint Thanks for the help but I believe i don't need to construct any special DHCP package in my case. Netgate explained to me that the "Auto" link speed function only works with both, the netgate device and the device on the other end (ONT in this case), are set to Auto. Since the SG-1100 could not get a negotiate a link speed when it was set to "auto", they suggested that it didn't work because the ONT must have been set to manual. I connected my workstation directly to the ONT and windows set the connection speed to 100Mbps. Therefore, the connection on the ONT must have been set up to "Manual 100Mbps". With this information, i set the link speed of the WAN port on my SG-1100 to manual 100Mbps and it negotiated a public IP in no time. I called verizon and they confirmed that the ONT was set to manual 100Mbps. They also told me that they could not remotely change the link speed to 1Gpbs or the type to "auto". If i ever wanted a faster internet connection then they would have to replace the ONT since it is a hardware limitation of the ONT i currently have installed. So, with that, this issue has been resolved on my end.

@viragomann adding that for outbound NAT, unfortunately, doesn't fix the problem, still can't ping/curl from the firewall. The VPN interfaces don't have any firewall rules (and work from the internal VLAN/interfaces) is there anything else I need to do. pftop gives a state of 0:0 for localhost to external IPs and time to live exceeded when using the VPN interface, but I don't even see pftop entries when using the default WAN gateway.

Lessons learned: Make sure you clean up your old config (or do a re-install). During a change in virtual NICS a Captive portal setting was mapped to an interface that was not intended to have one. This isolated 1 vlan from the rest of the network. Solved.

You shouldn't need to rip or load anything or copy modules at all. ng_eth is in the kernel now and does not need to be manually loaded. If you did load something by hand it probably caused a problem, not solved it.