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

    OpenVPN design issue

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 610 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.
    • Y
      yumcheese
      last edited by yumcheese

      hi,
      I'm trying to setup openvpn in the following scenario:

      1. Have two pfsense boxes (called PF1 and PF2) to communicate with each other (ability to have an Synology NAS at each site backup to each other). Not sure if site-to-site is required.

      2. Have road warriors (iphone, laptop) able to vpn in to the main openvpn server (PF1). I setup PF1 using server mode: Remote Access (SSL/TLS+User Auth). I used the Client Export and am able to get an iphone to connect to PF1 without any problems. I can ping to devices on the LAN of PF1.

      To accomplish 1) above, I setup PF2 under the Client's tab with Server mode: Peer to Peer (SSL/TLS). I see the VPN up, but no traffic passes from LAN of PF2 to LAN of PF1. I cannot ping devices on the LAN of PF1. I can from the PF2 Diagnostics tab.

      Am I approaching this wrong? Should I create a separate Openvpn server on PF1 using the site-to-site documentation?
      It seems like it should almost work the way I'm currently doing it. When I look at routes on PF2, I see a route that sends traffic to the Tunnel Network for traffic destined to the LAN of PF1. I tried putting Client Specific Overrides on PF1, but that didn't seem to work.

      Any help much appreciated.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by Derelict

        I would use a second server for the site-to-site. Connect an OpenVPN client at the other site to that, not the remote access server.

        For backups I would seriously consider IPsec instead. It will generally be more performant.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • Y
          yumcheese
          last edited by yumcheese

          Thank you very much for the suggestion. I tried creating a new site-to-site OpenVPN connection and it didn't work. I finally figured out why I couldn't route to the server side LAN. I originally tried to do this w/ IPsec, but couldn't get it working. I found out that IPsec conflicts with OpenVPN per some VPN debugging documentation I read. Once I disabled the IPsec, it worked. Spent so many days on this, arghhh.

          Hopefully, the performance will be okay w/ OpenVPN; otherwise, I'll have to try IPsec again. Had problems with getting Mutual RSA to work.

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            @yumcheese said in OpenVPN design issue:

            I found out that IPsec conflicts with OpenVPN per some VPN debugging documentation I read. Once I disabled the IPsec, it worked. Spent so many days on this, arghhh.

            Not really. You just have to configure it correctly.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            Y 1 Reply Last reply Reply Quote 0
            • Y
              yumcheese @Derelict
              last edited by

              @Derelict said in OpenVPN design issue:

              @yumcheese said in OpenVPN design issue:

              I found out that IPsec conflicts with OpenVPN per some VPN debugging documentation I read. Once I disabled the IPsec, it worked. Spent so many days on this, arghhh.

              Not really. You just have to configure it correctly.

              I got the info. here:

              https://docs.netgate.com/pfsense/en/latest/book/openvpn/troubleshooting-openvpn.html

              • Ensure no overlapping IPsec connections
                Because of the way IPsec ties into the FreeBSD kernel, any enabled IPsec connection matching the local and remote subnets that exists when IPsec is enabled (even if it is not up) will cause that traffic to never be routed across the OpenVPN connection. Any IPsec connections specifying the same local and remote networks must be disabled. If an IPsec tunnel has been recently disabled or removed, check that its SPD entries have been removed by looking at Status > IPsec on the SPD tab. If they are present, remove them from that screen.

              If you know of any good Mutual RSA IPsec examples, please let me know. Someone once told me that IPsec was more secure than OpenVPN. Not sure if still true or not. Thanks.

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                Traffic selectors have nothing to do with whether or not the authentication is RSA or shared-key.

                Configure your routing and traffic selectors properly and it will work.

                There is not going to be a walkthrough specific to your scenario unless you yourself write it.

                You'll have to post more details about your situation to get more specific assistance.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

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