OpenVPN Interface routes on VPN Slave with no active OpenVPN connection



  • Hi all,

    I run a dual setup of virtualised OpenVPN Instances which connect my management networks back to a central location.

    Private Network
      –-CARP---
    [VPN 1] [VPN 2]
      –-CARP--- <- OpenVPN uses CARP IP on the Public side
    Public Network

    Essentially I have the following setup where I have a CARP IP which sits on the Master with an OpenVPN Server service. The same is replicated to the slave. The OpenVPN service is only active on the Master because of CARP.

    However, looking at the route table on the slave, it still has an OVPNS1 interface up and entries in the route table relevant to the configuration.

    What this means is that over my VPN I'm unable to reach my slave because he sends traffic back up his OVPNS1 interface as his route table reflects that.

    I feel like this isn't really a desirable outcome, if the OpenVPN process can't run then an interface and associated routes shouldn't be up and present. If they weren't present my Backup VPN would fall back to a default route to the local network who would then appropriately re-route him up to the CARP Gateway on the local network which is held by the Primary and all would work fine.

    Is this a bug or an intended outcome of how OpenVPN works on PFSense?

    Keep in mind, I can't introduce a static route on the Backup for the VPN networks because 1. I sync routes and 2. When it fails over the route table will hold the Static route and cause a loop for the network on to the CARP IP and not send it up to the OVPNS1 Interface (I accidentally tested this theory).

    Any ideas?



  • You can make the slave reachable by adding an outbound NAT rule to the LAN interface, translating packets for slave (enter its internal IP at destination) to the interface address (LAN address).

    To also reach the other box while the second one is master, add an alias with both internal IPs and enter this in the NAT rule as destination instead the slaves IP.



  • @viragomann:

    You can make the slave reachable by adding an outbound NAT rule to the LAN interface, translating packets for slave (enter its internal IP at destination) to the interface address (LAN address).

    To also reach the other box while the second one is master, add an alias with both internal IPs and enter this in the NAT rule as destination instead the slaves IP.

    Great idea, I suppose the other result is to stand up a proxy device too but this may be cleaner and can sync between both devices.

    Thanks for the alternative idea :) I hadn't considered using NAT in that way to masquerade my VPN IP towards the other VPN host.



  • Just following up on this, I noticed this in my BACKUP's general logs the other day when doing some patching (newest logs on top):

    Jun 30 10:51:31 php-fpm /rc.carpbackup: Stopping OpenVPN instance on WAN because of transition to CARP backup.
    Jun 30 10:51:31 php-fpm /rc.carpbackup: HA cluster member "(<sanitised>@xn0): (WAN)" has resumed CARP state "BACKUP" for vhid 2
    Jun 30 10:51:30 php-fpm /rc.carpbackup: HA cluster member "(<sanitised>@xn1): (LAN)" has resumed CARP state "BACKUP" for vhid 1
    Jun 30 10:51:29 check_reload_status Carp backup event

    So if it's stopping the OpenVPN instance, why is it not killing the ovpns1 interface?

    Edit: just adding some logs from OpenVPN logs as well (newest logs on top):

    Jun 30 10:51:31 openvpn 66262 Initialization Sequence Completed
    Jun 30 10:51:31 openvpn 66262 UDPv4 link remote: [undef]
    Jun 30 10:51:31 openvpn 66262 UDPv4 link local (bound): [AF_INET]<sanitised address="">:1195
    Jun 30 10:51:31 openvpn 66262 /usr/local/sbin/ovpn-linkup ovpns1 1500 1574 <sanitised ip="" addresses="">init
    Jun 30 10:51:31 openvpn 66262 /sbin/ifconfig ovpns1 <sanitised ip="" addresses="">mtu 1500 netmask 255.255.255.255 up
    Jun 30 10:51:31 openvpn 66262 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Jun 30 10:51:31 openvpn 66262 TUN/TAP device /dev/tun1 opened
    Jun 30 10:51:31 openvpn 66262 TUN/TAP device ovpns1 exists previously, keep at program end
    Jun 30 10:51:31 openvpn 66262 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    Jun 30 10:51:31 openvpn 65974 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
    Jun 30 10:51:31 openvpn 65974 OpenVPN 2.3.11 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on May 16 2016
    Jun 30 10:51:31 openvpn 5038 SIGTERM[hard,] received, process exiting
    Jun 30 10:51:31 openvpn 5038 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1574 <sanitised ip="" addresses="">init
    Jun 30 10:51:31 openvpn 5038 event_wait : Interrupted system call (code=4)

    So the process closes because of failover but re-opens even though it is not master? then when failover occurs it tries to reopen the interface from what I can see.

    Is this really intended behaviour?</sanitised></sanitised></sanitised></sanitised></sanitised></sanitised>



  • That's the expected behavior. You need source NAT to access the system with backup status from a VPN via the system with master status.



  • @cmb:

    That's the expected behavior. You need source NAT to access the system with backup status from a VPN via the system with master status.

    Hi CMB,

    Thank you for the clarification, I can understand why that might be the case, a bit unfortunate as the Source NAT feels like a bit of a hack but I'll try it out and continue with that :)

    Thank you!

    Edit: Just tested it and it works like a dream, anything to get rid of crappy static routes. Fantastic, thank you again!


Log in to reply