Netgate 1537, OpenVPN & CARP High Availability
-
Hi,
we're currently replacing some Virtual pfSense Instances with Netgate 1537 Instances. Those are mainly used for Remote Access using OpenVPN. Generally speaking they work somewhat flawlessly but I'm having a little trouble to get OpenVPN in combination with CARP working.
I did setup CARP (and it works fine, all instances and the CARP IP are available by ICMP), OpenVPN is bound to the CARP IP and nmap on the same reports port 1194/tcp to be "open|filtered", so something's "listening" there. OpenVPN on the MASTER is up & running, the BACKUP reports the daemon isn't working (expected).
CARP IPs for LAN & WAN are reporting a proper status between primary & secondary, Manual Failover through "Status => CARP" is working as expected.
NAT Rules are setup to be Manual with LAN & OpenVPN Networks being translated to the CARP IP from WAN (others like the 127.0.0.1/8) go to WAN address.
But when it comes to OpenVPN Connectivity things are timing out.
I'm pretty sure this is a somewhat basic setup and I followed docs available but cannot get things working.
Just to mention, when NAT is set to "automatic", OpenVPN is bound to "WAN Address" and my Client connects to the actual Instance IP rather than the CARP IP things work flawlessly - so I'd suspect the issue being somewhere in the CARP/NAT area.
I'd appreciate help ..
BR,
Christian -
@cboenning said in Netgate 1537, OpenVPN & CARP High Availability:
But when it comes to OpenVPN Connectivity things are timing out.
What do you get on the client exactly?
Run a packet capture on WAN to ensure that the OpenVPN packets are arriving correctly.
Just to mention, when NAT is set to "automatic", OpenVPN is bound to "WAN Address" and my Client connects to the actual Instance IP rather than the CARP IP things work flawlessly - so I'd suspect the issue being somewhere in the CARP/NAT area.
The outbound NAT has no influence on incoming connections at all.
-
@viragomann We indeed had very strange routing issues on the location the pfSense instances are deployed. It's really nothing wrong with them but we had a strange situation in combination with our WAN Switches and the LACP upstream to the provider.
OpenVPN to the CARP Address is now running stable.