Navigation

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

    Routing Traffic Between 2 PFsense and Remote Site IPSEC

    Routing and Multi WAN
    4
    8
    140
    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.
    • F
      fgunno last edited by

      Hello

      I have 2 pfSense that can talk together via Static routing. Everything work fine.
      But now I need to setup a remote site with a IPSEC VPN on pfSense1 and the remote site need to access some network on the pfSense2.

      The traffic is not passing from VPN to pfSense2 at this time, And I cannot find how I can fix that...

      1 Reply Last reply Reply Quote 0
      • L
        lfoerster last edited by

        Maybe missing or wrong firewall rules on the virtual tunnel interface.
        Do you have a full established IPSec tunnel ?
        General Setup can be seen here:
        https://administrator.de/wissen/ipsec-vpn-praxis-standort-kopplung-cisco-ipcop-pfsense-fritzbox-297320.html
        Perhaps Google translator is your friend here.. ?!

        F 1 Reply Last reply Reply Quote 0
        • F
          fgunno @lfoerster last edited by

          @lfoerster

          IPSEC Tunnel is UP, can ping any IP on PFSENSE1
          PFSENSE1 can ping any IP on PFSENSE2 via Static Routing,
          But IPSEC cannot ping any IP on PFSENSE2...

          Rule are all OPEN on all interface (for testing purpose)

          1 Reply Last reply Reply Quote 0
          • L
            lfoerster last edited by lfoerster

            @fgunno said in Routing Traffic Between 2 PFsense and Remote Site IPSEC:

            PFSENSE1 can ping any IP on PFSENSE2 via Static Routing,

            Static routing is NOT necessary, cause tahts autmatically established in the IPsec phase 2 negotiation. Btw. you can proof that too in checking the pfSense routing table on both ends !
            Anyway...ich you can ping bith ends here on pFSense 1 and 2 then everything is fine ! You have your site 2 site VPN successfully established then !
            The question "But IPSEC cannot ping any IP on PFSENSE2..." is not understandable... The inner IPsec network is not relevant for the site to site connectivity in any ways ?!
            So what do you mean here ??

            1 Reply Last reply Reply Quote 0
            • F
              fgunno last edited by

              Pfsense 1 ans Pfsense2 are on same site.

              The IPsec VPN are on a remote site and connected via Static routing to Pfsense1.

              So the problem is that the remote site cannot ping to the pfsense2 on main site....

              1 Reply Last reply Reply Quote 0
              • L
                lfoerster last edited by lfoerster

                Did you follow there steps:
                IPsec site2site
                Usually its a no brainer. Click and it should work. With a simple single LAN on local and remote site NO addintional static routes are necessary ! Thats all handled automaticall by IPsec !

                If your tunnel is up an running then the only obstacle maybe a wrong or missing firewall rule here !
                You have to check 4 (four) interfaces here
                Rule on local LAN and local IPsec interface
                Rule on remote LAN and remote IPsec interface
                If in doubt use a simple "shotgun" rule with Source: any Destination: any on all interfaces to not create any trap here.

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

                  what did you see when you traceroute to IP DEST from some server connected to IPSEC VPN on PFSENSE1?

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

                    I had a similar issue. My advice is to make sure that the routes defined on PFSENSE2 include a route to your IPSEC subnet with PFSENSE1 as the gateway for that route.

                    Ultimately, for me, what was happening is that PF1 correctly routed the traffic from the external VPN through to PF2, but PF2 didn't have a route back to the IPSEC subnet, so it didn't know where to send the response.

                    See topic "Routing OpenVPN Clients to Tinc VPN" in this forum for more details.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post

                    Products

                    • Platform Overview
                    • TNSR
                    • pfSense
                    • Appliances

                    Services

                    • Training
                    • Professional Services

                    Support

                    • Subscription Plans
                    • Contact Support
                    • Product Lifecycle
                    • Documentation

                    News

                    • Media Coverage
                    • Press
                    • Events

                    Resources

                    • Blog
                    • FAQ
                    • Find a Partner
                    • Resource Library
                    • Security Information

                    Company

                    • About Us
                    • Careers
                    • Partners
                    • Contact Us
                    • Legal
                    Our Mission

                    We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                    Subscribe to our Newsletter

                    Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                    © 2021 Rubicon Communications, LLC | Privacy Policy