fd0d13e9-1456-4a43-9261-b77d3a0c1cce-afbeelding.png

uncheck this apparently I had this turned on.

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

Well, unless I'm misunderstanding this thread, I think I may just be out of luck unless I recompile the kernel with the newer modules (which wouldn't really be an option):

https://forums.freebsd.org/threads/custom-kernel-driver-modules.14998/

Does anyone else have any thoughts / suggestions? Thanks in advance.

@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 =>

9EFD731F-0E6C-48E3-B46E-95EFD937FB48.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
be01e3f0-9d6c-49a0-ad07-52bd239ca1f6-image.png
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.
1d84f43e-ca38-4e1b-bc89-272b36ec45dd-image.png
and when you have GW1 down
40b81554-6f93-42b5-936b-a27aa3a2be3b-image.png
FW makes a failover to WAN2 regardless of the rules setting to use only GW1
7e980426-2fb3-4609-85a4-c77e96dd657c-image.png

Only if I set default GW to something different than GW group like automatic or ether GW
10ea2306-6833-429b-b52e-65a91ea0a868-image.png
Then the GW settings on FW rules are followed/respected:
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.

Yes it is:
https://redmine.pfsense.org/issues/855

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.

ok resolved
https://forum.netgate.com/topic/161221/proxmox-ovh-no-route-added-to-gw-after-upgrade-to-2-5-0/3

Thank you

Well yeah, which I clearly stated beginning of this thread that you would need a gateway and routes to your downstream networks

https://forum.netgate.com/post/965347

I had to go under System>Routing>Gateways and created a LAN Gateway pointing to the 10.100.10.3 device

So your still using 10.100 as your transit?? Again this is wrong!!

@vbman213

You'd have to look at the traffic. If s_port and d_port are always 5060 you could restrict the port in the rule, but often on the return trip the d_port will be some random port (the originating s_port), so port filtering will be impractical. In any event, you'd be filtering inbound on your providers IP address(es). And, now that I'm thinking about it I'm not sure how NAT will behave, if at all. I honestly wouldn't try it unless there really, really, really, wasn't any other choice and you had the time and patients to mess with it.

TCP, if you can use it, should enhance reliability and security. Trying not to keep state on UDP will cost you time, possibly degrade security, but maybe solve your issue without having to reconfigure clients. The right tools for the job are TCP for the SIP protocol, and UDP for the RTP streams. I'm not sure what the vendor rational is for UDP as a default... other than maybe using one protocol type for both use cases, and RTP over TCP would end badly.

@wifi-will bump

@viktor_g Thank you. The patch is working fine.

2021-02-22_00-59.png

@viktor_g

Hi, yes, seems to be pretty much exactly the same.

Sometimes I ask myself if netgates quality crontrol takes a week off before releasing... I mean - IPv6 static routes, complex changes and bugs in handling of the ipsec connectsions.... these are mandatory things, and I don't think the issues are only related to the community edition, or are they?

Cheers
4920441

@pfsense16v My issue was not with my main WAN connection. It was with a backup WAN2 connection via a 4G router where the router would not pass IP to the pfsense correctly after upgrading the firmware.

The issue was resolved by changing the 4G router on the WAN2 for a Zyxel LTE3302-M432 4G router.

*** UPDATE ***

I tried a fresh install of 21.02 and still had the same WAN dropping issues.

I re-installed 2.4.5 p1 and my WAN connection is rock solid. No issues.

Hoping to hear of a resolution soon before I attempt the upgrade again.

@traveller

Thank you. Don't know how I missed that.

Indeed, forcing a monitoring IPv6 address fixes the issue.

@taytos said in Speedtest upload always 0.1mbit when using pfsense as gateway:

VirtIO

FWIW https://docs.netgate.com/pfsense/en/latest/virtualization/virtio.html