Netgate 7100 with HA update issues
-
Do both devices have public IPs? If you have a shared single public IP only the master node would have connectivity.
Otherwise check for a default route in Diag > Routes.
-
@stephenw10 Both devices have public ip's AND there is a virtual public ip, which we use to usually access it, but also for the openvpn, for the RDS servers that run behind it,...
The outbound nat rules (:anual outbound NAT rule) are the same on both devices and use the virtual wan ip to get out
-
What outbound NAT rules do you have exactly?
Importantly the rules should not include traffic from the firewall itself. Otherwise only the node owning the shared VIP will be able to connect as traffic is translated to it.
-
-
Hmm... That's fun. Two weeks ago, I found that 1.1.1.1 was not responding to my pings anymore. Additionally, on one of the CARP firewalls, it was used for gateway monitoring. I don't really know what's happening, but I used an alternative, 8.8.4.4, which worked fine, and I just forgot about it until I read your story. I don't know if it's related, but what is the status of your gateway on the status page?
-
-
@nick-loenders
Ok, so it is not related.
Did your try traceroute from diagnostic menu? Some public ip or Microsoft.com, anyone? -
@w0w @stephenw10
very weird stuff here, I did a tracert and ping and I had internet....
Also the 24.03 update was visible and I could install it...Now it has rebooted, the internet is gone again...
So I need to wait another day before it comes back.... -
Did you check the default route?
-
@stephenw10 where do I check this, I have no static routes setup
-
@stephenw10 said in Netgate 7100 with HA update issues:
Otherwise check for a default route in Diag > Routes.
Also check that the default route shown there is valid/expected assuming it is there.
-
@stephenw10 NO idea how that actually works but here it is:
-
Ok, that looks good.
Can you test a ping to, say, 8.8.8.8 from the command line on that node?
Whilst that ping is running check the state table in Diag > States. Filter it by 8.8.8.8 and make sure the outbound state exists and on the correct interface.
-
@stephenw10 Well then there is no reply, in the states it says:
-
Hmm, what is that connected to? How are the other NICs connected?
I assume the primary node can ping everything OK?
-
@stephenw10 the primary node can ping perfectly
The WAN nics are connected to a patchpanel and get a direct ip from the hosting in the datacenter.
WAN on pri;ary is .35
WAN on secondary is .36
Virtual WAN for HA and how we go out is .33 (if we are on a server and do whatismyip.com we see .33 ) -
Hmm. Traffic just disappearing like that I start to suspect something odd upsteam.
Check on the primary node to see if replies are somehow being incorrectly sent to it. So you would see that in the firewall log there unless you have rules to pass it.
I assume the CARP VIPs are all failing over correctly?
-
I do see this on the firewall, don't know what that is:
I already added that to the rules, but it does not help.
I do seem not to be able to ping the other SYNC side:
-
@stephenw10 nevermind the ping, I solved that by a rule
-
I wouldn't expect to see CARP multicast traffic on the SYNC interface. There shouldn't normally be a CARP VIP on it.
I also wouldn't expect that to make any difference to secondary connectivity though.
Try pinging something from the secondary and then running a pcap on the primary WAN for that same target and see if packets are coming back incorrectly there.
