Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense can't ping VPN Client on TUN network

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 2.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      marteng
      last edited by

      Hello,

      i've got a strange problem:

      My clients can connect to the internal network over OpenVPN (from pfSense 2.1) without any problem. They have pushed routes and are able to reach all internal networks like intended. I can ping all internal servers/clients but not the other way around.

      There is no problem with the Windows firewall of the clients. Two OpenVPN(TUN)-clients can see and ping each other while connected over the vpn with their virtual ip addresses 192.168.37.2 and .3. . All routing tables (internal clients/servers, pfSense itself and OpenVPN-Clients) are correct. The problem:

      The pfSense cannot even ping its own gateway-ip for the OpenVPN virtual tunnel network adapter (192.168.37.1) - though it is listet in the routing table correctly.

      The Problem must be the routing/firewall of the pfSense.

      Does anybody have a hint for me?

      Thank You.
      Martin

      1 Reply Last reply Reply Quote 0
      • M
        marteng
        last edited by

        I think I found the problem:

        Mar 20 12:13:10 openvpn[24400]: OpenVPN 2.3.2 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jul 24 2013
        Mar 20 12:13:10 openvpn[24400]: WARNING: using –duplicate-cn and --client-config-dir together is probably not what you want
        Mar 20 12:13:10 openvpn[24400]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
        Mar 20 12:13:10 openvpn[24400]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
        Mar 20 12:13:10 openvpn[24400]: TUN/TAP device ovpns1 exists previously, keep at program end
        Mar 20 12:13:10 openvpn[24400]: TUN/TAP device /dev/tun1 opened
        Mar 20 12:13:10 openvpn[24400]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
        Mar 20 12:13:10 openvpn[24400]: /sbin/ifconfig ovpns1 192.168.37.1 192.168.37.1 mtu 1500 netmask 255.255.255.0 up
        Mar 20 12:13:10 openvpn[24400]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1558 192.168.37.1 255.255.255.0 init
        Mar 20 12:13:10 openvpn[26354]: UDPv4 link local (bound): [AF_INET]192.168.12.29:1194
        Mar 20 12:13:10 openvpn[26354]: UDPv4 link remote: [undef]
        Mar 20 12:13:10 openvpn[26354]: Initialization Sequence Completed

        In the OpenVPN-logs i can see that the ovpns1 virtual adapter is initialized with this command:

        /sbin/ifconfig ovpns1 192.168.37.1 192.168.37.1 mtu 1500 netmask 255.255.255.0 up

        Is it correct to list the ip address here twice and how can i change that from shell without completely reconfiguring the the openvpn server through web frontend?

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by

          @marteng:

          Is it correct to list the ip address here twice and how can i change that from shell without completely reconfiguring the the openvpn server through web frontend?

          There is nothing to fix here, leave it alone.

          1 Reply Last reply Reply Quote 0
          • M
            marteng
            last edited by

            Thank you, i can see that.

            Another pfsense is working without problems and I can ping the ovpns-Interface ip-address of the tunnel network from the pfsense itself. So it must be a problem with the pfSense-installation I'm testing right now. I will backup the setup and reinstall it this evening.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.