@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