OpenVPN Issue with 2.4 upgrade



  • I have an issue where after upgrading pfsense to 2.4, it seems to keep the existing dynamic route and fails to connect.

    ifconfig fails error 1

    This obviously is correct because the previous route is already there and it cant use it again.

    The ip address assigned to me by the VPN server was 10.9.0.1.  After changing the IP address the server was using (DHCP and is now 10.3.0.2), the client connected without a problem.  Below you can see the errant route in the routing table that I can't seem to delete.

    10.3.0.0/24 10.3.0.1 UGS 0 1500 ovpnc3
    10.3.0.1 10.3.0.2 UGHS 112937 1500 lo0
    10.3.0.2 link#16 UHS 1419 16384 lo0
    10.9.0.1 10.3.0.2 UGHS 40269480 1500 lo0

    Has anyone else had this issue?



  • Yes, I had this issue when testing development builds.  I reported it in the 2.4 development builds forum but it was ignored because nobody else was seeing problems.

    I reverted back to 2.3.4 and all works well again.  I won't upgrade to 2.4.x until this is fixed.  The non-removal of dynamic routes should be an obvious fix.



  • Do you have the link to the issue you reported so I can also link to this issue.

    Are you using two openvpn clients by any chance?  I have two separate VPN Clients that are routed to two different VLANs.



  • @RHLinux:

    Do you have the link to the issue you reported so I can also link to this issue.

    Are you using two openvpn clients by any chance?  I have two separate VPN Clients that are routed to two different VLANs.

    I brought up the problems I was seeing in a thread in the 2.4 development subforum.  I didn't submit an official bug report.

    When testing I was using two different openvpn clients but I have no VLANs created.

    Do you see problems with gateway monitoring with the two openvpn clients running? I did.



  • @cosmoxl:

    @RHLinux:

    Do you have the link to the issue you reported so I can also link to this issue.

    Are you using two openvpn clients by any chance?  I have two separate VPN Clients that are routed to two different VLANs.

    I brought up the problems I was seeing in a thread in the 2.4 development subforum.  I didn't submit an official bug report.

    When testing I was using two different openvpn clients but I have no VLANs created.

    Do you see problems with gateway monitoring with the two openvpn clients running? I did.

    Yes I had issues with the gateway monitoring… then it would not connect at all or would be erratic.  I eventually notice in the openvpn log that the ifconfig command would fail and after looking at the route status in diagnostics noticed it had an old dynamic route that should of been deleted.  I ended up changing the dynamic ip address of the openvpn server and that seemed to fix the problem, however the old route was still there.



  • @RHLinux:

    @cosmoxl:

    @RHLinux:

    Do you have the link to the issue you reported so I can also link to this issue.

    Are you using two openvpn clients by any chance?  I have two separate VPN Clients that are routed to two different VLANs.

    I brought up the problems I was seeing in a thread in the 2.4 development subforum.  I didn't submit an official bug report.

    When testing I was using two different openvpn clients but I have no VLANs created.

    Do you see problems with gateway monitoring with the two openvpn clients running? I did.

    Yes I had issues with the gateway monitoring… then it would not connect at all or would be erratic.  I eventually notice in the openvpn log that the ifconfig command would fail and after looking at the route status in diagnostics noticed it had an old dynamic route that should of been deleted.  I ended up changing the dynamic ip address of the openvpn server and that seemed to fix the problem, however the old route was still there.

    Yep, at the time I posted everybody insisted that all was good.  Nobody else reported problems.  I feel a little vindicated now.  I won't upgrade to 2.4.x until this problem is fixed.



  • I'm having maybe the same problem with the 2.4.1 upgrade (from 2.3.4-RELEASE-P1).  Two sites connected by OpenVPN, each with multi-WAN and Multi-WAN, spanned by OpenVPN. Both sites have a road warrior VPN as well although one is for backup admin access.

    VPNs still connects but with the following issues:

    1. site 1 primary LAN traffic for site 2 primary LAN doesn't go down the tunnel despite the routing tables being correct. It's routed out the current WAN interface. Site 2 primary LAN traffic for site 1 passes normally.

    2. road warrior traffic for site 1 appears to work normally with the caveat of #1 (traffic to site 2 isn't sent down the VPN tunnel despite the routing tables).

    3. road warrior traffic for site 2 only reaches the firewall and goes no further.

    Complicating matters is that my primary development platform, an ultrabook, is out for warranty repair again because it doesn't power on, I can't access my image backups that are in the file system backup for that from the temporary development platform although I've got config backups handy locally and with autoconfigbackup, these as on Soekris 6501's (Soekris went belly up with means I'm down to dregs for spares), and these 32-bit nano images on USB.

    Worse yet, Netgate seems to oddly restrict legacy downloads of an opensource project (see comment above about access to backups; I've got basically all versions there).

    And I'm remote. Previously, I had redundant firewalls at both sites but the client made a bad cost cutting move to drop to one (large retail).

    Anyone know where legacy downloads are?



  • "I'm having maybe the same problem with the 2.4.1 upgrade (from 2.3.4-RELEASE-P1). "

    Correction. Upgrade to 2.3.4-RELEASE-P1 from 2.3.3.



  • I am also having the problem of an old route that doesn't get deleted (also on 2.4.1)

    /sbin/ifconfig ovpnc1 10.4.6.92 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
    ifconfig fails error 1

    From netstat:
    10.4.0.1          10.4.3.89          UGHS        lo0

    Trying manually:

    /sbin/ifconfig ovpnc1 10.4.6.92 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
    ifconfig: ioctl (SIOCAIFADDR): File exists

    Trying to delete the old route:

    route del 10.4.0.1 10.4.3.89
    route: writing to routing socket: Address already in use
    del host 10.4.0.1: gateway 10.4.3.89 fib 0: gateway uses the same route

    If I reboot or flush the routes it will work again until my ADSL goes down.



  • When will the devs pay attention to this?



  • Who knows… It's defiantly still an issue with multi client/multi WAN.

    RHLinux


  • Rebel Alliance Developer Netgate

    @cosmoxl:

    When will the devs pay attention to this?

    When we have some solid evidence other than vague reports that it's broken with barely any detail. I have probably 30-40 OpenVPN instances between my lab and live boxes, a mix of clients, servers, multi-WAN, routing protocols, you name it. I have yet to see this happen. About the only thing I don't have is a connection to an external VPN provider. I have simulated one internally, but I don't subscribe to any public ones.

    We're going to need a lot more detail about the specific configurations in play here on both sides when it happens, more details from the logs, OS routing tables, anything that might be relevant.



  • @jimp:

    @cosmoxl:

    When will the devs pay attention to this?

    When we have some solid evidence other than vague reports that it's broken with barely any detail. I have probably 30-40 OpenVPN instances between my lab and live boxes, a mix of clients, servers, multi-WAN, routing protocols, you name it. I have yet to see this happen. About the only thing I don't have is a connection to an external VPN provider. I have simulated one internally, but I don't subscribe to any public ones.

    We're going to need a lot more detail about the specific configurations in play here on both sides when it happens, more details from the logs, OS routing tables, anything that might be relevant.

    OK.  In another thread user gave me the tip that solves the problem - that is to stop specifying a different IP address to ping for gateway monitoring.  That fixed the problem for me.

    Perhaps that helps you understand the problem.



  • I have this problem too. Since upgrading to pfSense 2.4.x my OpenVPN client stays connected until a change in WAN is detected (cable disconnect, IP change, etc) after that it starts giving out ifconfig errors and it wont connect anymore unless I reboot my pfsense box. The problem seems to be VPN routes are not being deleted when vpn goes down. I went back to 2.3.4 and the problem is gone. I will stay on 2.3.4 until this is fixed.



  • @cosmoxl:

    OK.  In another thread user gave me the tip that solves the problem - that is to stop specifying a different IP address to ping for gateway monitoring.  That fixed the problem for me.

    Perhaps that helps you understand the problem.

    What different IP should we use? I am using 10.4.0.1 which is gateway of AirVPN provider.


  • Rebel Alliance Developer Netgate

    If setting a monitor IP address on the VPN gateway triggered it, then that makes me wonder if it's related to how the routes are added.

    Anyone having the issue, check for:

    1. Is the VPN interface assigned/enabled under the Interfaces menu?
    2. Does the VPN gateway have an alternate monitoring IP address?
    3. Is there a DNS server set to use the VPN gateway?
    4. Are there any manually-defined static routes set to the use VPN gateway? (there should never be, but some people add them not realizing they are a problem)
    5. Any dynamic routing protocols using the VPN?



  • 1. Is the VPN interface assigned/enabled under the Interfaces menu? - Yes. Removed the interface and no change. Readded interface, no change.
    2. Does the VPN gateway have an alternate monitoring IP address? - It did (it was one of the client expected IP addresses). Removed the alternate monitoring IP, no change.
    3. Is there a DNS server set to use the VPN gateway? - No
    4. Are there any manually-defined static routes set to the use VPN gateway? (there should never be, but some people add them not realizing they are a problem) - No
    5. Any dynamic routing protocols using the VPN? - No

    I do have an OpenVPN client (to my VPN provider) running alongside and separate to the OpenVPN server.


  • Rebel Alliance Developer Netgate

    Even if I try to intentionally break it that way, it still restarts fine for me. I do see a route hanging around for the gateway monitor IP address but it doesn't prevent anything from working, and when the VPN restarts it goes right back online. No errors.

    I am using 2.4.2 to test this, however. Maybe something else changed there along the way that fixed the problem. Either that or I still don't have enough detail to reproduce the original issue.



  • 1. Is the VPN interface assigned/enabled under the Interfaces menu? Yes.
    2. Does the VPN gateway have an alternate monitoring IP address? I have to check this.
    3. Is there a DNS server set to use the VPN gateway? Yes, same as VPN gateway.
    4. Are there any manually-defined static routes set to the use VPN gateway? No.
    5. Any dynamic routing protocols using the VPN? No.

    I am using AirVPN. My VPN gateway, DNS and Monitoring IP are all 10.4.0.1.


  • Rebel Alliance Developer Netgate

    @amires:

    3. Is there a DNS server set to use the VPN gateway? Yes, same as VPN gateway.
    I am using AirVPN. My VPN gateway, DNS and Monitoring IP are all 10.4.0.1.

    On System > General Setup, do not set a gateway on the DNS server there. Just leave the entry for 10.4.0.1 and set the gateway to "none". You're making a redundant route by doing that, which could be part of the problem. If 10.4.0.1 is your VPN gateway then you'll already have a route there. Selecting that on the DNS server list is completely unnecessary. We prevent that for static IP interfaces where the network is known, but since those VPN interfaces are dynamic it isn't prevented.

    You're lucky that didn't cause a problem in the past.



  • @jimp:

    @amires:

    3. Is there a DNS server set to use the VPN gateway? Yes, same as VPN gateway.
    I am using AirVPN. My VPN gateway, DNS and Monitoring IP are all 10.4.0.1.

    On System > General Setup, do not set a gateway on the DNS server there. Just leave the entry for 10.4.0.1 and set the gateway to "none". You're making a redundant route by doing that, which could be part of the problem. If 10.4.0.1 is your VPN gateway then you'll already have a route there. Selecting that on the DNS server list is completely unnecessary. We prevent that for static IP interfaces where the network is known, but since those VPN interfaces are dynamic it isn't prevented.

    You're lucky that didn't cause a problem in the past.

    Actually I have tried it both without a gateway and with VPN gateway and none did help. I just removed the gateway just to be safe.
    I also removed 10.4.0.1 as monitoring ip and used 8.8.8.8 instead. I am waiting to see if the problem still exist.


  • Rebel Alliance Developer Netgate

    @amires:

    Actually I have tried it both without a gateway and with VPN gateway and none did help. I just removed the gateway just to be safe.
    I also removed 10.4.0.1 as monitoring ip and used 8.8.8.8 instead. I am waiting to see if the problem still exist.

    Depending on the steps you took in between attempts that may not have been a relevant test. You can use the gateway for the monitor IP address, that's what it does by default. Leave the monitor IP address field blank. Setting something else may be part of the overall issue (though it works fine here).

    This may not be relevant to you, but to others: If you do need to use a DNS server across the VPN, do not set the gateway on the DNS server list, but add the DNS server IP address/32 to the remote network list of your VPN client. That way OpenVPN will manage the route. But to reiterate, that is NOT necessary if the DNS server is directly connected or especially if it is your VPN gateway.



  • @jimp:

    @amires:

    Actually I have tried it both without a gateway and with VPN gateway and none did help. I just removed the gateway just to be safe.
    I also removed 10.4.0.1 as monitoring ip and used 8.8.8.8 instead. I am waiting to see if the problem still exist.

    Depending on the steps you took in between attempts that may not have been a relevant test. You can use the gateway for the monitor IP address, that's what it does by default. Leave the monitor IP address field blank. Setting something else may be part of the overall issue (though it works fine here).

    This may not be relevant to you, but to others: If you do need to use a DNS server across the VPN, do not set the gateway on the DNS server list, but add the DNS server IP address/32 to the remote network list of your VPN client. That way OpenVPN will manage the route. But to reiterate, that is NOT necessary if the DNS server is directly connected or especially if it is your VPN gateway.

    Thanks for your help. When I leave the monitoring IP blank then pfsense will use locally assigned VPN IP as the monitoring IP which is not a reliable way to check availability of the link. I need to monitor other side of the link which is 10.4.0.1 therefore I am forced to either manually enter 10.4.0.1 as monitoring IP or use a different pingable public IP but then I wouldn't be able to monitor RTT of the VPN link.

    If it helps here are the relevant VPN routes from my routing table when I am using 10.4.0.1 as both DNS and monitoring IP.

    Destination        Gateway            Flags    Netif Expire
    10.4.0.0/16        10.4.0.1            UGS      ovpnc1
    10.4.0.1            10.4.x.y            UGHS    ovpnc1
    10.4.x.y              link#9              UHS      lo0



  • Well, I tested two concurrent OVPN clients connected, both with alternate IP monitored, and stopping and reconnecting one of them.

    This would have caused a problem (ifconfig and/or gateway monitoring saying gateway was down) when I was testing 2.4 a few months ago but didn't cause a problem today.

    I'm at a loss, because I know others are still having problems.



  • This morning the mentioned errors appeared again. OpenVPN wont connect and I had the following errors in the logs :

    /sbin/ifconfig ovpnc1 10.4.4.12 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
    FreeBSD ifconfig failed: external program exited with error status: 1
    Exiting due to fatal error

    I checked the routing table and I noticed that I have the following VPN route  :

    10.4.0.1          10.4.4.12          UGHS        lo0

    I tried manually deleting the route :

    route del  10.4.0.1
    route: writing to routing socket: Address already in use
    del host 10.4.0.1 fib 0: gateway uses the same route

    I restarted my pfsense box at this point. After restarting everything was ok again.


  • Rebel Alliance Developer Netgate

    @amires:

    /sbin/ifconfig ovpnc1 10.4.4.12 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
    FreeBSD ifconfig failed: external program exited with error status: 1
    Exiting due to fatal error

    I tried manually deleting the route :
    route del  10.4.0.1
    route: writing to routing socket: Address already in use
    del host 10.4.0.1 fib 0: gateway uses the same route

    If that happens again, post the entire contents of "netstat -rn" and "ifconfig -a" and "ps uxaww | grep openvpn" before attempting to delete the route. Something else must still be running/using that address.



  • @jimp:

    If that happens again, post the entire contents of "netstat -rn" and "ifconfig -a" and "ps uxaww | grep openvpn" before attempting to delete the route. Something else must still be running/using that address.

    It happended again and it won't connect anymore. I am posting below the information your requested.

    netstat -rn

    Destination        Gateway            Flags     Netif Expire
    default            ADSL_GATEWAY       UGS      pppoe0
    10.4.0.1           10.4.4.12          UGHS        lo0
    8.8.8.8            192.168.1.1        UGHS        em0
    127.0.0.1          link#4             UH          lo0
    172.16.0.0/30      link#1             U           re0
    172.16.0.2         link#1             UHS         lo0
    ADSL_GATEWAY       link#8             UH       pppoe0
    ADSL_IP            link#8             UHS         lo0
    192.168.1.0/24     link#2             U           em0
    192.168.1.2        link#2             UHS         lo0
    192.168.2.0/24     link#3             U           em1
    192.168.2.1        link#3             UHS         lo0
    8.8.4.4            pppoe0             UHS      pppoe0
    

    ifconfig -a

    re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate>ether xx:xx:xx:xx:xx:xx
            hwaddr xx:xx:xx:xx:xx:xx
            inet6 fe80::6666:b3ff:fe03:5569%re0 prefixlen 64 scopeid 0x1
            inet 172.16.0.2 netmask 0xfffffffc broadcast 172.16.0.3
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether xx:xx:xx:xx:xx:xx
            hwaddr xx:xx:xx:xx:xx:xx
            inet6 fe80::7254:d2ff:feab:20a6%em0 prefixlen 64 scopeid 0x2
            inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    em1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
            options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether xx:xx:xx:xx:xx:xx
            hwaddr xx:xx:xx:xx:xx:xx
            inet6 fe80::7254:d2ff:feab:20a7%em1 prefixlen 64 scopeid 0x3
            inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active
    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
            options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
            inet 127.0.0.1 netmask 0xff000000
            nd6 options=21 <performnud,auto_linklocal>groups: lo
    enc0: flags=0<> metric 0 mtu 1536
            nd6 options=21 <performnud,auto_linklocal>groups: enc
    pflog0: flags=100 <promisc>metric 0 mtu 33160
            groups: pflog
    pfsync0: flags=0<> metric 0 mtu 1500
            groups: pfsync
            syncpeer: 224.0.0.240 maxupd: 128 defer: on
            syncok: 1
    ovpnc1: flags=8010 <pointopoint,multicast>metric 0 mtu 1500
            options=80000 <linkstate>nd6 options=21 <performnud,auto_linklocal>groups: tun openvpn
    pppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492
            inet ADSL_IP --> ADSL_GATEWAY  netmask 0xffffffff
            inet6 xxxx::xxxx:xxxx:xxxx:xxxx%pppoe0 prefixlen 64 scopeid 0x8
            nd6 options=21<performnud,auto_linklocal></performnud,auto_linklocal></up,pointopoint,running,noarp,simplex,multicast></performnud,auto_linklocal></linkstate></pointopoint,multicast></promisc></performnud,auto_linklocal></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate></up,broadcast,running,simplex,multicast>
    

    ps uxaww | grep openvpn

    root    31186   0.0  0.0  14728   2432  0  S+   22:21     0:00.00 grep openvpn
    


  • I have the same issue.

    I even went into System -> Routing and deleted the disabled gateways from there that were no longer active after removing the OpenVPN Server.

    As follows:

    netstat -rn
    Routing tables
    
    Internet:
    Destination        Gateway            Flags     Netif Expire
    default            10.1.1.1           UGS         re0
    8.8.8.8            172.21.34.53       UGHS        lo0
    10.1.1.0/24        link#1             U           re0
    10.1.1.254         link#1             UHS         lo0
    10.8.0.2           10.8.0.1           UGHS        lo0
    61.9.242.33        10.1.1.1           UGHS        re0
    127.0.0.1          link#4             UH          lo0
    172.21.34.0/23     172.21.34.1        UGS      ovpnc2
    172.21.34.1        link#8             UH       ovpnc2
    172.21.34.53       link#8             UHS         lo0
    192.168.1.0/24     link#2             U           re1
    192.168.1.1        link#2             UHS         lo0
    198.18.0.1         172.21.34.53       UGHS        lo0
    198.18.0.2         172.21.34.53       UGHS        lo0
    208.67.220.220     172.21.34.53       UGHS        lo0
    208.67.222.222     172.21.34.53       UGHS        lo0
    
    Internet6:
    Destination                       Gateway                       Flags     Netif Expire
    ::1                               link#4                        UH          lo0
    fe80::%re0/64                     link#1                        U           re0
    fe80::428d:5cff:fe52:d947%re0     link#1                        UHS         lo0
    fe80::%re1/64                     link#2                        U           re1
    fe80::1:1%re1                     link#2                        UHS         lo0
    fe80::%lo0/64                     link#4                        U           lo0
    fe80::1%lo0                       link#4                        UHS         lo0
    fe80::428d:5cff:fe52:d947%ovpnc2  link#8                        UHS         lo0
    
    ps uxaww | grep openvpn
    root    71827   0.0  0.2  20332  6320  -  Ss   Tue18     18:03.62 /usr/local/sbin/openvpn --config /var/etc/openv
    pn/client2.conf
    root    89326   0.0  0.1  14728  2312  0  S+   06:43      0:00.00 grep openvpn
    
    ifconfig -a
    re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate>ether 40:8d:5c:52:d9:47
            hwaddr 40:8d:5c:52:d9:47
            inet6 fe80::428d:5cff:fe52:d947%re0 prefixlen 64 scopeid 0x1 
            inet 10.1.1.254 netmask 0xffffff00 broadcast 10.1.1.255 
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    re1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate>ether 40:8d:5c:52:d9:45
            hwaddr 40:8d:5c:52:d9:45
            inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 
            inet6 fe80::1:1%re1 prefixlen 64 scopeid 0x2 
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active
    enc0: flags=0<> metric 0 mtu 1536
            nd6 options=21 <performnud,auto_linklocal>groups: enc 
    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
            options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet6 ::1 prefixlen 128 
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 
            inet 127.0.0.1 netmask 0xff000000 
            nd6 options=21 <performnud,auto_linklocal>groups: lo 
    pflog0: flags=100 <promisc>metric 0 mtu 33160
            groups: pflog 
    pfsync0: flags=0<> metric 0 mtu 1500
            groups: pfsync 
            syncpeer: 224.0.0.240 maxupd: 128 defer: on
            syncok: 1
    ovpnc2: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::428d:5cff:fe52:d947%ovpnc2 prefixlen 64 scopeid 0x8 
            inet 172.21.34.53 --> 172.21.34.1  netmask 0xfffffe00 
            nd6 options=21 <performnud,auto_linklocal>groups: tun openvpn 
            Opened by PID 71827</performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast></promisc></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast></performnud,auto_linklocal></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,linkstate></up,broadcast,running,simplex,multicast>
    

    I currently have no OpenVPN server configured as Ive done these commands.



  • I am also having the same issue.

    netstat -rn

    Routing tables
    
    Internet:
    Destination        Gateway            Flags     Netif Expire
    default            WAN1_GW            UGS        bge1
    8.8.4.4            WAN2_GW            UGHS       bge2
    8.8.8.8            WAN1_GW            UGHS       bge1
    9.9.9.9            WAN2_GW            UGHS       bge2
    10.4.0.1           10.4.28.44         UGHS        lo0
    127.0.0.1          link#4             UH          lo0
    WAN1_RANGE/24      link#2             U          bge1
    192.168.0.0/22     link#1             U          bge0
    WAN1_IP            link#2             UHS         lo0
    192.168.1.1        link#1             UHS         lo0
    WAN2_RANGE/27      link#3             U          bge2
    WAN2_IP            link#3             UHS         lo0
    208.67.220.220     WAN1_GW            UGHS       bge1
    208.67.222.222     WAN2_GW            UGHS       bge2
    

    ifconfig -a

    bge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=c009b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,vlan_hwtso,linkstate>ether xx:xx:xx:xx:xx:xx
            hwaddr xx:xx:xx:xx:xx:xx
            inet6 xxxx::xxx:xxxx:xxxx:xxxx%bge0 prefixlen 64 scopeid 0x1
            inet 192.168.1.1 netmask 0xfffffc00 broadcast 192.168.3.255
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
            status: active
    bge1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8009b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate>ether xx:xx:xx:xx:xx:xx
            hwaddr xx:xx:xx:xx:xx:xx
            inet6 xxxx::xxx:xxxx:xxxx:xxxx%bge1 prefixlen 64 scopeid 0x2
            inet WAN1_IP netmask 0xffffffe0 broadcast 255.255.255.255
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex,master>)
            status: active
    bge2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8009b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate>ether xx:xx:xx:xx:xx:xx
            hwaddr xx:xx:xx:xx:xx:xx
            inet6 xxxx::xxx:xxxx:xxxx:xxxx%bge2 prefixlen 64 scopeid 0x3
            inet WAN2_IP netmask 0xffffffe0 broadcast 255.255.255.255
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex,master>)
            status: active
    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
            options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
            inet 127.0.0.1 netmask 0xff000000
            nd6 options=21 <performnud,auto_linklocal>groups: lo
    enc0: flags=0<> metric 0 mtu 1536
            nd6 options=21 <performnud,auto_linklocal>groups: enc
    pflog0: flags=100 <promisc>metric 0 mtu 33160
            groups: pflog
    pfsync0: flags=0<> metric 0 mtu 1500
            groups: pfsync
            syncpeer: 224.0.0.240 maxupd: 128 defer: on
            syncok: 1
    ovpnc1: flags=8010 <pointopoint,multicast>metric 0 mtu 1500
            options=80000 <linkstate>nd6 options=21 <performnud,auto_linklocal>groups: tun openvpn</performnud,auto_linklocal></linkstate></pointopoint,multicast></promisc></performnud,auto_linklocal></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast></full-duplex,master></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate></up,broadcast,running,simplex,multicast></full-duplex,master></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,vlan_hwtso,linkstate></up,broadcast,running,simplex,multicast>
    

    ps uxaww | grep openvpn

    root 24877   0.0  0.0  14728  2432  0  S+   21:21      0:00.00 grep openvpn
    

    1. Is the VPN interface assigned/enabled under the Interfaces menu? Yes.
    2. Does the VPN gateway have an alternate monitoring IP address? No.
    3. Is there a DNS server set to use the VPN gateway? No.
    4. Are there any manually-defined static routes set to the use VPN gateway? No.
    5. Any dynamic routing protocols using the VPN? No.

    I currently have 1 AirVPN client configured and no OpenVPN servers configured. Hope this helps.



  • An update from me.

    I would say that the fault lays here:

    Any OpenVPN gateways under System -> Routing that were present with an alternate monitoring IP prior to 2.4.1 are the cause of the issue.

    I went through and deleted the following:
    OpenVPN Server, Interface, CA, Certs, Gateways

    I am now able to

    1. Stop and start the OpenVPN server correctly without having to reboot
    2. Have alternate IP monitoring respond correctly via dpinger.


  • @jarrad:

    An update from me.

    I would say that the fault lays here:

    Any OpenVPN gateways under System -> Routing that were present with an alternate monitoring IP prior to 2.4.1 are the cause of the issue.

    I went through and deleted the following:
    OpenVPN Server, Interface, CA, Certs, Gateways

    I am now able to

    1. Stop and start the OpenVPN server correctly without having to reboot
    2. Have alternate IP monitoring respond correctly via dpinger.

    That is good to know.  I also cleared all the above but still had some issues.  I also had an alternative monitoring IP address (monitoring the other end of the link) and had this issue only when upgrading.  I ended up changing the IP address of the link and rebooted the system.  This seemed to fix the problem.

    RHLinux



  • I have clean installed pfSense 2.4.1 and made all the necessary configs all by hand and still have this issue. I am going to disable ip monitoring
    for OpenVPN and see if that helps.

    I found out that is not just a WAN IP change that triggers this, there are other circumstances involved. I manually forced WAN IP change many
    times and OpenVPN client recovered successfully every time. So it is not just a WAN IP change that triggers this.

    By the way I am not using OpenVPN Server, it is the OpenVPN Client that I have issues with.

    UPDATE : I haven't had any more issues since I have disabled gateway monitoring on OpenVPN Client interface. My pfSense machine has been
    up for 3 days now without any kind of problem.



  • I spoke too soon.

    It broke as soon as I added a second client.

    I've since rebuilt it again from scratch and now the server won't assign itself an IP so routing internally is broken but clients can communicate.

    This also coincided with the upgrade to 2.4.2.



  • Still having this same issue. It seems to happen upon any manual changes to the routes or if OpenVPN loses it's connection and attempts to reestablish it, giving these errors:

    Nov 30 10:16:28	openvpn	89059	TUN/TAP device ovpnc1 exists previously, keep at program end
    Nov 30 10:16:28	openvpn	89059	TUN/TAP device /dev/tun1 opened
    Nov 30 10:16:28	openvpn	89059	do_ifconfig, tt->did_ifconfig_ipv6_setup=0
    Nov 30 10:16:28	openvpn	89059	/sbin/ifconfig ovpnc1 10.4.28.44 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
    Nov 30 10:16:28	openvpn	89059	FreeBSD ifconfig failed: external program exited with error status: 1
    Nov 30 10:16:28	openvpn	89059	Exiting due to fatal error
    

    It appears the only way to fix it (albeit temporarily) is to reboot and wait for it to happen once more.

    10.4.0.1           10.4.28.44         UGHS        lo0
    

    This is the leftover route that seems to be causing the issue, and any attempt to remove it manually gives:

    [2.4.2-RELEASE][root@pfSense.local.lan]/dev: route delete 10.4.0.1
    route: writing to routing socket: Address already in use
    delete host 10.4.0.1 fib 0: gateway uses the same route
    

    I have tried multiple iterations of the above route command with no success. I've manually removed the ovpnc1 interface, tun device. No luck. Any ideas?



  • Hitting the same issues and I'm also using AirVPN as my vpn provider.  I have 3 OpenVPN connections on my 2.4.2 install:

    Site to Site with shared key
    Remote access
    Client connection to AirVPN

    Site to site and remote access haven't had any problems and the client connection to AirVPN only causes troubles when I've set an explicit monitor IP.  Once I removed the monitor IP, the AirVPN connection hasn't caused me any problems.  Once I add the monitor IP, the connection is fine until it drops and needs to reconnect (for whatever reason) then it won't reconnect with the same ifconfig error as reported by others.  That same static route for the monitor IP hangs around as reported by others and I simply can't get it to go away nor can I get the tunnel to AirVPN to reconnect unless I:

    1. reboot pfSense OR
    2. Change the port I connect to AirVPN on, which then changes the link IP on the connection from 10.6.0.0/16 to say 10.4.0.0/16 which then let's everything reconnect but with that extra static route hanging around and then when it disconnects again then I now have two static routes that hang around, etc.

    And to answer the questions posed earlier in the thread:

    1. Is the VPN interface assigned/enabled under the Interfaces menu? Yes
    2. Does the VPN gateway have an alternate monitoring IP address? Yes (when I hit this problem, but for now I've removed the explicit monitor IP and haven't had any problems)
    3. Is there a DNS server set to use the VPN gateway? No
    4. Are there any manually-defined static routes set to the use VPN gateway? (there should never be, but some people add them not realizing they are a problem) No
    5. Any dynamic routing protocols using the VPN? No


  • Rebel Alliance Developer Netgate

    So now my question is this: Is there anyone having this problem that is NOT using AirVPN?

    It may be triggered by some option pushed to the client by AirVPN. Rather than focusing on the disconnection, get some logs from when AirVPN connects, maybe with an increased verb level that will show what they are pushing.



  • @jimp:

    So now my question is this: Is there anyone having this problem that is NOT using AirVPN?

    It may be triggered by some option pushed to the client by AirVPN. Rather than focusing on the disconnection, get some logs from when AirVPN connects, maybe with an increased verb level that will show what they are pushing.

    Here is a full log from OpenVPN set to the highest verbosity level.

    https://pastebin.com/29eWQCGY



  • @SirJohnEh:

    Site to site and remote access haven't had any problems and the client connection to AirVPN only causes troubles when I've set an explicit monitor IP.  Once I removed the monitor IP, the AirVPN connection hasn't caused me any problems.  Once I add the monitor IP, the connection is fine until it drops and needs to reconnect (for whatever reason) then it won't reconnect with the same ifconfig error as reported by others.  That same static route for the monitor IP hangs around as reported by others and I simply can't get it to go away nor can I get the tunnel to AirVPN to reconnect unless I:

    Leave gateway monitoring enabled, but do not put in an IP address to monitor. Does that work for you?



  • Yes it does.  The only issue is it ends up monitoring its own IP address, which isn't very useful, but yes it does work (and it's what I'm actually doing now as a workaround).



  • That seems to be a workaround for me as well.


Log in to reply