CARP - Not able to access the LAN IP of the Backup pfSense machine
-
"Interface address" is fine here.
The alias contains both LAN addresses of master and backup?Please post a screenshot of the outbound NAT page.
Here you go…
-
Well I got the LAN interface working on the pfsense backup machine. It was the ports on my switch….
Now I am troubleshooting the WAN interface on the pfsense backup machine. For some reason, I cannot ping the WAN interface (192.168.50.3) on the backup pfsense machine. I am able to ping the pfSense master WAN IP (192.168.50.2) and the WAN Virtual IP (192.168.50.254) from the 192.168.1.0/24 subnet.. What in world is my problem?
-
Why would you care about reaching the secondary's WAN interface in that fashion?
It should work as long as there is outbound NAT out the primary's WAN. if not you will probably be looking at an asymmetric routing issue.
-
Why would you care about reaching the secondary's WAN interface in that fashion?
It should work as long as there is outbound NAT out the primary's WAN. if not you will probably be looking at an asymmetric routing issue.
Based on my setup, should I be able to reach the pfSense backup WAN IP (192.168.50.3/24) while the pfSense master machine is active and without an outbound NAT?
I assume when the backup becomes the master, I should be able to ping the pfSense backup WAN IP (192.168.50.3/24).
-
Yes, it should be reachable if your WAN interfaces and the WAN VIP are in the same network segment and if the firewall rules allow the ping to WAN.
-
Yes, it should be reachable if your WAN interfaces and the WAN VIP are in the same network segment and if the firewall rules allow the ping to WAN.
I am only able to ping the pfSense backup WAN IP (192.168.50.3) only when there is a failover and the pfSense backup becomes the master. The failover seems to be working fine. Just I cannot figure out this issue.
You mentioned firewall rules and outbound NAT rules. Can you provide some detail on specific things to check..
-
That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?
Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?
Can you ping the secondary's WAN IP address from the primary? Then it's working.
Can you ping the secondary's LAN address from LAN? Then it's working.
Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.
-
That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?
Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?
Can you ping the secondary's WAN IP address from the primary? Then it's working.
Can you ping the secondary's LAN address from LAN? Then it's working.
Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.
Here is the diagram with the WAN IP addresses unmasked…
-
That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?
Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?
Can you ping the secondary's WAN IP address from the primary? Then it's working.
Can you ping the secondary's LAN address from LAN? Then it's working.
Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.
I cannot ping the pfSense backup WAN IP address (192.168.50.3) from the pfSense master machine (see attachment).
I can ping the pfSense backup LAN IP address (10.1.1.3) from the pfSense master machine (see attachment)
-
That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?
Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?
Can you ping the secondary's WAN IP address from the primary? Then it's working.
Can you ping the secondary's LAN address from LAN? Then it's working.
Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.
I got it working.. On the WAN interface on the backup pfSense machine, I had to untick the "Block private networks and loopback addresses" and "Block bogon networks" options. See attachments.
