nat/firewall/ha not working
-
Hmm, I assume that IP you are NATing to is the CARP VIP?
On the primary node that works check the states created when it checks for updates. What source IP is it using? The CARP VIP?
We did see issues with the primary IP address on an interface moving to a VIP on it but that should be solved. Also I never saw it affect pkg operations.
-
@stephenw10 yes, but actually not really...
the configuration is like this:
10.10.0.1 is the CARP VIP of the interface
213.137.54.24/29 (to be exact 8 single /32 IPs) are virtual IPs based on the CARP VIPthis is done to more quickly move all the IPs following the CARP VIP and to minimize CARP traffic between the firewalls
@stephenw10 said in nat/firewall/ha not working:
On the primary node that works check the states created when it checks for updates
with three machines and that many interfaces there are too much states to go through to analyze
can you share the update servers' subnet? is208.123.73.212part of it? (if so, from the states it seems the source IP is10.10.0.2, the IP of the interface, so not NATted) -
Ah so the IPs from 213.137.54.24/29 are IPAliases that are on the 10.10.0.1 CARP VIP?
What is NATing the 10.10.0.X subnet then, some upstream router?
If there's nothing NATing that then the nodes would have to use IPs from the public /29 directly. But since those are on the CARP VIP only the master node can use it.
Why not use IPs from the /29 directly on the nodes?
-
S stephenw10 referenced this topic on
-
@stephenw10 said in nat/firewall/ha not working:
What is NATing the 10.10.0.X subnet then, some upstream router?
correct, the Cisco router
@stephenw10 said in nat/firewall/ha not working:
Why not use IPs from the /29 directly on the nodes?
a. to have all of them available
b. there will be no /29, I'm slowly migrating services to a single /32 -
Hmm, then there should be no problem with them using the primary IP in the 10.10.0X subnet as long as it' not the CARP VIP.
Do you not see states at all on the other nodes?