[SOLVED] Strange: CARP IPSEC tunnel; can ping far side fw1, but NOT fw2??
-
Having a strange issue, been working at it for a while but no luck.
Configuration:
2x pfSense 2.1.5 boxes on either end of an IPSec tunnel. Both ends are in an HA+CARP configuration.
Main site: 172.16.1.0/24
LAN Virtual IP: 172.16.1.2
LAN fw1 IP: 172.16.1.3
LAN fw2 IP: 172.16.1.4Branch site: 172.16.5.0/24
LAN Virtual IP: 172.16.5.1
LAN fw1 IP: 172.16.5.2
LAN fw2 IP: 172.16.5.3Everything working great (traffic passing through tunnel, routing working as expected, etc).
BUT, from Main site, I can successfully ping branch fw1 (172.16.5.1 or 172.16.5.2) but cannot ping or reach in any way fw2 (172.16.5.3). However, when I power cycle branch fw1 and fw2 takes over, suddenly I can reach it by both IP addresses (.5.1 and .5.3). Then when fw1 takes back over, branch fw2 becomes unreachable at .5.3 again.
There is nothing in the firewall logs. I'm guessing it's something to do with firewall rules regarding permitted subnets but due to CARP the firewalls have identical configs.
-
This is a known issue, there was something in the wiki (or somewhere), but I can't find it right now.
You can only hit the firewall which is holding up the tunnel via the tunnel, the backup one won't have the route active.
You might be able to fix it by adding a route on the lan via the lan carp to the remote subnet, but I just connect to the public ip when I need to configure the backup. -
This is a known issue, there was something in the wiki (or somewhere), but I can't find it right now.
You can only hit the firewall which is holding up the tunnel via the tunnel, the backup one won't have the route active.
You might be able to fix it by adding a route on the lan via the lan carp to the remote subnet, but I just connect to the public ip when I need to configure the backup.OK, good to know, I spent hours going through all the config options trying to figure out what I was doing wrong, so that's a relief :).
Thanks for taking time to post the info. -
You just need source NAT to manage cross-subnet (whether VPN or otherwise) to work around the lack of routing when in backup status. You don't want to modify routing to try to work around it, you will break something when it fails over. There are examples of that kind of outbound NAT in the book.