Openvpn not working after upgrade to 2.1



  • Hi all,
    after I upgraded from 2.0.3 to version 2.1 openvpn is not working correctly.It worked like a charm before the upgrade.No problems at all.After the upgrade clients seem to connect to LAN but they cannot ping or connect to anything inside it.They can only ping the LAN gateway.No configuration changes have been made after the upgrade.I see that other people have the same issue.



  • Post your OpenVPN config, OpenVPN rules, LAN subnet details and an example of what does not work. Then we can try and help with your particular problem, and maybe also discover what happens with the upgrade config.



  • @phil.davis:

    Post your OpenVPN config, OpenVPN rules, LAN subnet details and an example of what does not work. Then we can try and help with your particular problem, and maybe also discover what happens with the upgrade config.

    This. I'm having an issue with my OpenVPN and seeing your config might help me too :)



  • I'm attaching openvpn setup.Lan subnet (as also seen in openvpn setup is 192.168.1.0/24)
    Rules were created using the openvpnwizard.
    Client setup was also made using openvpn client export utility.Everything worked perfect on version 2.0.3.

    Theres no example to post.Openvpn Clients connect to pfsense and…then they can do nothing apart from ping LAN ADDRESS (192.168.1.1).Name resolution does not work.No application can be opened.They cannot ping no pc inside the LAN.Is just like pfsense is blocking them from doing anything.All of these things worked perfect before.

    I mention again that no configuration change took place after the upgrade and nothing (seemed to)went wrong during the upgrade process.








  • And the rules






  • I am experiencing a similar scenario.  I also used the OpenVPN Exporter prior to the upgrade to configure the clients.

    OpenVPN was working well prior to the upgrade but post upgrade, it works but no longer forces all traffic through the VPN as it used to.  In general, all of the resources on my network are still accessible as before, just the traffic is not properly forced through the VPN.  :-\



  • Yeah - I might go to my server configuration and click the:

    redirect gateway:  Force all client generated traffic through the tunnel.



  • @kejianshi:

    Yeah - I might go to my server configuration and click the:

    redirect gateway:  Force all client generated traffic through the tunnel.

    I've tried it both ways and it doesn't appear to be working as before.  I've also tried the command:

    push "redirect-gateway def1"

    in the advanced section but the results are the same either way.



  • No idea - So far 2 people have settings posed - may as well make it three.

    Its hard to know whats up without settings.



  • @vradelos:

    And the rules

    The rule on the OpenVPN tab is pushing the traffic out to WANGW. There should be no gateway specified there. Edit the rule and remove the gateway selection from the advanced section.
    The same thing seems to have happen to a rule on WAN - but that rule probably doesn't break anything because the traffic that matches it is the incoming connects to the OpenVPN server on the firewall itself, so the real packets are probably beinf delivered locally to the OpenVPN server and not getting processed out back to WANGW. You should remove the gateway from that also, just to be sure.
    It would be very interesting to see what these rules looked like in 2.0.n before the upgrade. Is there something in the upgrade that is picking selecting a gateway all by itself? or what?



  • That was the problem Phil thank you! I really can't remember what the rules looked like before the upgrade. The thing is that the rules were created with the wizard and since everything worked before the upgrade,they had to be correct right?So something during the upgrade messed the rules up.



  • Do you have a backup of the config from 2.0.n?
    It would be good to see what the rules were like previously - rules section and the interfaces and gateways section.



  • Below is a chunk of the 2.0.3 backup containing the openvpn wizard rules(if i'm not mistaken).It looks like the gateway was not set  to WANGW before the upgrade.

    • <rule><id><type>pass</type>
        <interface>openvpn</interface>
        <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype>
        <os>- <source>
        <any>- <destination><any></any></destination>

    • <descr>-   ]]></descr>
        <associated-rule-id>nat_51e92376013d09.00644968</associated-rule-id></any></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>

    • <filter>- <rule><id><type>pass</type>
        <interface>wan</interface>
        <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype>
        <os><protocol>udp</protocol>

    • <source>
        <any>- <destination><network>wanip</network>
        <port>1194</port></destination>

    • <descr>-   ]]></descr></any></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule></filter>



  • I am sorry, a little lost by the solution.

    OpenVPN tab? and do what? In there I see gateway in advanced but have the options of default or ppoe…

    How do I select "none"?



  • @Honeybadger:

    I am sorry, a little lost by the solution.

    OpenVPN tab? and do what? In there I see gateway in advanced but have the options of default or ppoe…

    How do I select "none"?

    Rules on the OpenVPN tab apply to incoming traffic from the client/s to the server. In the advanced section of the rule(s) the gateway should normally just be "default" (there is no "none"). "default" will send the packets to the ordinary routing table, which is what you usually want.



  • Oh, darn.

    Hoped this would fix my OpenVPN setup that stopped working post 2.1 upgrade.

    Looks like the same set up as these guys.



  • Whats wrong with yours?



  • Was working before 2.1 upgrade…

    Not I don't think it even sees the attemp to link, the log doesn't show any attempt:
    Sep 24 13:37:30 openvpn[306]: Initialization Sequence Completed
    Sep 24 13:37:30 openvpn[306]: UDPv4 link remote: [undef]
    Sep 24 13:37:30 openvpn[306]: UDPv4 link local (bound): [AF_INET]93.222.11.20:1194
    Sep 24 13:37:30 openvpn[98937]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1558 192.168.200.1 192.168.200.2 init
    Sep 24 13:37:30 openvpn[98937]: /sbin/ifconfig ovpns1 192.168.200.1 192.168.200.2 mtu 1500 netmask 255.255.255.255 up
    Sep 24 13:37:30 openvpn[98937]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Sep 24 13:37:30 openvpn[98937]: TUN/TAP device /dev/tun1 opened
    Sep 24 13:37:30 openvpn[98937]: TUN/TAP device ovpns1 exists previously, keep at program end
    Sep 24 13:37:30 openvpn[98937]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
    Sep 24 13:37:29 openvpn[98937]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    Sep 24 13:37:29 openvpn[98937]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jul 24 2013
    Sep 24 13:37:28 openvpn[62798]: SIGTERM[hard,] received, process exiting
    Sep 24 13:37:28 openvpn[62798]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1558 192.168.200.1 192.168.200.2 init
    Sep 24 13:37:28 openvpn[62798]: event_wait : Interrupted system call (code=4)
    Sep 24 13:36:12 openvpn[62798]: Initialization Sequence Completed
    Sep 24 13:36:12 openvpn[62798]: UDPv4 link remote: [undef]
    Sep 24 13:36:12 openvpn[62798]: UDPv4 link local (bound): [AF_INET]93.222.11.20:1194
    Sep 24 13:36:11 openvpn[61611]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1558 192.168.200.1 192.168.200.2 init
    Sep 24 13:36:11 openvpn[61611]: /sbin/ifconfig ovpns1 192.168.200.1 192.168.200.2 mtu 1500 netmask 255.255.255.255 up
    Sep 24 13:36:11 openvpn[61611]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Sep 24 13:36:11 openvpn[61611]: TUN/TAP device /dev/tun1 opened
    Sep 24 13:36:11 openvpn[61611]: TUN/TAP device ovpns1 exists previously, keep at program end
    Sep 24 13:36:11 openvpn[61611]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
    Sep 24 13:36:10 openvpn[61611]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    Sep 24 13:36:10 openvpn[61611]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jul 24 2013
    Sep 24 13:36:10 openvpn[59284]: SIGTERM[hard,] received, process exiting
    Sep 24 13:36:09 openvpn[59284]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1558 192.168.200.1 192.168.200.2 init
    Sep 24 13:36:09 openvpn[59284]: event_wait : Interrupted system call (code=4)

    Thanks for asking and helping!



  • I normally only post to these forums when I have a problem, so I feel pretty excited that I can post a possible fix for OpenVPN issues.  I realize this isn't going to be a catch-all fix, but be sure you don't change too much if you have problems with 2.1 after upgrading.

    In my case, I have pfsense at my house and my mom's house - the link works fine on 2.x and I had it working flawlessly for several months.  A friend of mine says "hey, 2.1 is out, and I've been running fine" - so being like most geeks that take their friends at face value, I said "OKAY!"

    I upgraded my mom's connection first - all was well.  the VPN link still worked fine.  So I upgraded mine.  Fark.  That broke the OpenVPN link.  Both sides would report the link as being down.

    Fortunately I had a Dynamic DNS client installed on a management PC on her network and I connected to discover that the link was indeed down.

    Turns out that the upgrade had ONLY wiped the configuration data under  VPN > OpenVPN > Client > Edit > Advanced was empty

    I followed the tooltip there and entered the remote IP of MY network (the "host" network) plus the OpenVPN port of 1194 and hit save.  Within mere seconds the link was restored.

    I realize this may not work for everyone, but keep in mind the first rule of troubleshooting - start with the easiest solution first and go from there.



  • I don't seem to have a client section at all, blank.

    Don't remember if I did have anything there.



  • It depends.  Your server is pfsense, but is the client like a windows machine or linux or something or is the client another pfsense?

    If the client is pfsense, one end will have a server config and the client side will have a client config.

    If not, then your pfsense will only have a server config and the client runs on windows or whatever.



  • I'd need to see your server configuration to know what is wrong.  Also, what kind of OS is the client?



  • Never mind all, turned out to be some weird problem updating between my server and my DDNS service.

    All solved now and thanks!


Log in to reply