@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
And LAN rules are set to use only GW1 172.16.0.1/24 only, do not use failover.
and when you have GW1 down
FW makes a failover to WAN2 regardless of the rules setting to use only GW1
Only if I set default GW to something different than GW group like automatic or ether GW
Then the GW settings on FW rules are followed/respected:
Hope I explained my query clearer now.
And my question is: Is this is expected behaviour?
@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
@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
@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.
@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.
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.
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?
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.