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

    Best Setup?

    OpenVPN
    3
    20
    5.5k
    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.
    • I
      Indigo64
      last edited by

      @cmb:

      Why do you have a port forward there? Most always don't want or need that for your OpenVPN client or server. I'd expect that to break your connectivity entirely, but maybe the connection established before the port forward(s) were there so it'll continue working until the client's IP changes or the client restarts. Sounds like it is functional but not routing, so you're likely missing the "remote network" field on one or both sides.

      So now you're telling me that I should have port forwards?  Make up your mind.  :P

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

        Second most likely cause (and the almost certain cause if you can ping the LAN IP on the remote side) is a host firewall on the client you're trying to reach.

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

          Port forwards are not firewall rules. It says Firewall>Rules, not Firewall>NAT. The problem with the document appears to be your reading comprehension.

          1 Reply Last reply Reply Quote 0
          • I
            Indigo64
            last edited by

            Yes, I hopped on that one too fast.  Sorry.

            I just checked, both of them have the requisite rules for their respective access to the OpenVPN connection.

            The remote "client" pfsense network can ping my host network, but I still cannot ping (or access) anything on the client network (nor can I ping its pfsense host)

            There are also no firewalls enabled on the other side for the test clients at this time.

            1 Reply Last reply Reply Quote 0
            • I
              Indigo64
              last edited by

              Nevermind.  Got it sorted.

              To get it working on both sides, and feel free to correct me if I made a mistake here…

              On Firewall > Rules:  WAN Tab:

              UDP  10.0.8.0/24  *    *  *  *    None

              On Firewall > Rules: OpenVPN Tab:

              *    *  *    *    *    *    None

              Applied to both sides, everything is pingable.

              I do notice that there's some pretty bad latency, so I'm not sure if this setup is invalid, or if it's just the DSL being...  well, DSL.

              1 Reply Last reply Reply Quote 0
              • I
                Indigo64
                last edited by

                Ugh this system setup is SO FRUSTRATING.

                I disabled the VPN link to see if there was a problem with the DSL (there was) but I brought it back up once the problem was resolved, but getting the connection back is akin to asking the impossible.

                Even after 45+ minutes, there's still no link up.  As you can see from above, it WAS working fine… why won't the link activate again?  NOTHING has changed, and stopping/restarting the service doesn't do anything.

                Why is this solution so difficult?  I use OpenVPN with Untangle for work and it's never been this hard to work with.

                1 Reply Last reply Reply Quote 0
                • I
                  Indigo64
                  last edited by

                  Removed & re-created the VPN using the same instructions/setup as before.

                  OH WHAT DO YOU KNOW?!?!!

                  Still. Does. Not. Work.

                  1 Reply Last reply Reply Quote 0
                  • I
                    Indigo64
                    last edited by

                    Followed this word for word.  Compared screenshots to my own views.

                    Guess what?

                    Still doesn't work.

                    http://blog.stefcho.eu/?p=576

                    1 Reply Last reply Reply Quote 0
                    • P
                      phil.davis
                      last edited by

                      One thing that is odd/possibly confusing to readers, on the "stefcho" blog is:

                      Server host or address, enter the WAN IP address on the first router pfSense01, in our case 10.10.2.2. Server port, whatever port you have used on the server, in our case the default 1194.

                      It looks like he his demo is on a completely private test setup, not over the real internet. His pfSense01 has a WAN IP address of 10.10.2.2 - so I guess he connected 2 pfSense WANs to a switch at home, then made an OpenVPN across the switch between the LANs of the 2 pfSense boxes.
                      In your post, I can't see any mention of the public IP of the server end. The client end needs to have the public IP of the server end.
                      Also, I just leave the encryption algorithm at the default.
                      Apart from that, the blog is what I do. I have a bunch of these site-to-site shared key links and they setup fine for me. Maybe there is something critical missing from the blog, but I didn't notice it.
                      Post screen shots of the server and client OpenVPN settings (rub out the shared key value), firewall rules on the WAN and OpenVPN.

                      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

                        That blog post is correct as well. No, not everyone who's ever written a site to site OpenVPN guide is conspiring against you. They really do work as illustrated.

                        My guess at this point is you have a general connectivity problem between client and server for some reason. Packet capture, check firewall states, for the outer 1194 or whatever port you picked.

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