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

    Network from VPN Server unreachable through the Lan

    Scheduled Pinned Locked Moved OpenVPN
    8 Posts 4 Posters 9.7k 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.
    • C
      cracker
      last edited by

      Pfsense is the VPN-Client. From the pfsense console i get a ping form all machines in the server network. but when i try to connect from a machine behind the pfsense client the network is unreachable.

      it seems to me like a firewall problem.

      When i use port forwarding it is possible to connect so the service in die server network, but only if the IF is set to wan or ppoe. But this not the way i want to use vpn.

      Thanks for your help

      1 Reply Last reply Reply Quote 0
      • D
        dvmoser
        last edited by

        I think I am experiencing the same problem.  Without a tun interface to play with, I cannot see the rules that are being applied.  I can access everything fine from inside the pfsense box but it will not pass traffic from the Lan side…  I did get it working a while ago by natting the tun interface but I dont think its a good fix.  I was wondering if anyone has a pfsense to pfsense vpn working properly.  Sorry I cant help but it might be nice to know that your not alone...

        1 Reply Last reply Reply Quote 0
        • N
          Numbski
          last edited by

          What version of pfSense are each of you running?  If the answer is not RC3 or better, update.

          Second, have you assigned your tun/tap to a pfSense interface?  If you have, stop it. :)  Delete that interface, and pfSense will automatically generate tun/tap any/any allow rules for you.

          Finally, if you are in a 3 network setup (ie, local net - tunnel net - remote net) make sure that each side of the tunnel has a route to the opposing network, otherwise traffic will not route!

          1 Reply Last reply Reply Quote 0
          • D
            dvmoser
            last edited by

            It looks like on the server end, the routes get created when you fill in the remote network field.  As far as the client, it seems to blow up when you enter the route for the other network and get a operation denied error when you ping clients over the vpn.  You have to completely remove things restart and go again.  HELP!!!

            1 Reply Last reply Reply Quote 0
            • C
              cracker
              last edited by

              Sorry, my mistake.

              I'm running RC3e (Updated a, b, c, d, e). The tun interface can not assigned any more. Because there seems to be a problem with the route-push option i had to add a static route on my pfsense-client to the servers network. The pfsense-client can ping to all machines in the server network. So the routes must be ok, don't they?
              But it's not possible to ping from the lan-side of the pfsense-client to the server or the server-network. May there a problem with the routes on the server side?

              Here my OVPN Log:

              Oct 11 19:05:18 openvpn[7640]: –- [SKD] Peer Connection Initiated with –-
              Oct 11 19:05:17 openvpn[92656]: Initialization Sequence Completed
              Oct 11 19:05:17 openvpn[92656]: Preserving previous TUN/TAP instance: tun0
              Oct 11 19:05:17 openvpn[92656]: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology (2.0.6)
              Oct 11 19:05:16 openvpn[92656]: [server] Peer Connection Initiated with –-
              Oct 11 19:05:13 openvpn[7640]: TCPv4_SERVER link remote: –-
              Oct 11 19:05:13 openvpn[7640]: TCPv4_SERVER link local: [undef]
              Oct 11 19:05:13 openvpn[7640]: TCP connection established with –-
              Oct 11 19:05:13 openvpn[7640]: Re-using SSL/TLS context
              Oct 11 19:05:12 openvpn[92656]: TCPv4_CLIENT link remote: –-
              Oct 11 19:05:12 openvpn[92656]: TCPv4_CLIENT link local: [undef]
              Oct 11 19:05:12 openvpn[92656]: TCP connection established with –-
              Oct 11 19:05:12 openvpn[92656]: Attempting to establish TCP connection with –-
              Oct 11 19:05:12 openvpn[92656]: Re-using SSL/TLS context
              Oct 11 19:05:12 openvpn[92656]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
              Oct 11 19:05:12 openvpn[92656]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
              Oct 11 19:05:07 openvpn[92656]: SIGUSR1[soft,ping-restart] received, process restarting
              Oct 11 19:05:07 openvpn[92656]: [server] Inactivity timeout (–ping-restart), restarting

              1 Reply Last reply Reply Quote 0
              • S
                sullrich
                last edited by

                You do not assign the tun interface.  Search the forum, this has been beaten to death like a dead horse.

                1 Reply Last reply Reply Quote 0
                • C
                  cracker
                  last edited by

                  That i had't to assign a tun interface is clear to me.

                  The routing problem is driving me crazy. When pfsense is the vpn-server the client can access the server net. it is not possible to connect to any system on the client side (same problem at the pfsense console). If pfsense is the client, it is not possible to connect from the server side to any system on the client side. But form the pfsense console it is possible to connect to all server side systems. But not from the lan behind the pfsense client. When i use nat (with IF pptp) i can forward some services into the client lan.

                  I'm really confused now!

                  This seems to be the reason why i had to add a static route when pfsense is the client:

                  Oct 11 19:36:25 openvpn[72511]: Initialization Sequence Completed
                  Oct 11 19:36:25 openvpn[72511]: ERROR: FreeBSD route add command failed: shell command exited with error status: 1
                  Oct 11 19:36:20 openvpn[72511]: /etc/rc.filter_configure tun0 1500 1543 192.168.220.6 192.168.220.5 init
                  Oct 11 19:36:20 openvpn[72511]: /sbin/ifconfig tun0 192.168.220.6 192.168.220.5 mtu 1500 netmask 255.255.255.255 up
                  Oct 11 19:36:20 openvpn[72511]: TUN/TAP device /dev/tun0 opened
                  Oct 11 19:36:20 openvpn[72511]: gw –-
                  Oct 11 19:36:20 openvpn[72511]: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology (2.0.6)
                  Oct 11 19:36:19 openvpn[72511]: [server] Peer Connection Initiated with –-
                  Oct 11 19:36:15 openvpn[72511]: TCPv4_CLIENT link remote: –-
                  Oct 11 19:36:15 openvpn[72511]: TCPv4_CLIENT link local: [undef]
                  Oct 11 19:36:15 openvpn[72511]: TCP/UDP: Dynamic remote address changed during TCP connection establishment
                  Oct 11 19:36:15 openvpn[72511]: TCP connection established with –-

                  1 Reply Last reply Reply Quote 0
                  • D
                    dvmoser
                    last edited by

                    Your not going to like to hear this but I went with IPSEC vpn's instead.  The interface is much more reliable and pfsense's implementation will allow you to configure the server as a remote client portal.  All the pfsense clients connect as if they were a site to site and it takes care of all routes beautifully.  It doesnt matter if they are dynamic or static ip's with this conifig also.  I will keep checking with OVPN and hopefully they will have all the kinks worked out soon.

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