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

    Static Route to adress a specific Gateway in the remote network?

    IPsec
    3
    11
    5.3k
    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.
    • W
      Wolfgang
      last edited by

      Hello,

      i have a working site to site IPSEC vpn. I'll call them siteA and siteB. Both sides uses a pfsense.

      At siteB, i have a specific gateway (call it RGW)for certain ip-adresses to connect to another remote network.
      I setup a static route on the pfsense a siteB to point to this RGW, so any host on siteB can access it, because they use the pfsense as the default gateway.

      Now i want hosts at siteA also give access to the RGW at siteB.
      I setup a static route on the pfsense at siteA to point to the RGW at siteB.

      To be more concret:
      siteA: 192.168.1.0/24
      siteB: 192.168.2.0/24
      RGW: 192.168.2.2 (router to access 10.0.0.24)
      Static Route Entry on pfsense (tried LAN and WAN as interface)
      10.0.0.24/32 Gateway: 192.168.2.2

      The problem:
      Using a traceroute to 10.0.0.24 on a host at siteA always returns: router (which is pfsense) returned: target not reachable ….
      However, from that host, i can still ping 192.168.2.2

      Doing the same on a host at siteB works fine.

      I assume that for some reasons, the static route entry has "connection" to the IPSEC VPN tunnel.

      Any ideas?

      Wolfgang

      1 Reply Last reply Reply Quote 0
      • H
        hoba
        last edited by

        The tunneldefinition determines what traffic goes through. Static routes won't work for IPSEC. As you can't sum up the remote subnets to one larger subnet you need parallel tunnels. For parallel tunnels to work you have to use unique identifiers for both tunnels (add them at vpn>ipsec, presharde keys tab) instead of using my IP-Adress. Otherwise the ipsectraffic gets messed up as both tunnels run between the same endpoints.

        Then create additional to the tunnel that you already have (after you changed it to use a unique identifier):

        siteA subnet 192.168.1.0/24  to  siteB 10.0.0.24/32

        You have to use this definition at both ends, so the local subnet at siteB is 10.0.0.24/32 and not LANsubnet in the IPSEC Tunneldefinition. Then just add the static route at siteB to 10.0.0.24/32.

        Don't forget to remove the the static route to 10.0.0.24/32 at siteA.

        1 Reply Last reply Reply Quote 0
        • W
          Wolfgang
          last edited by

          Thank you.
          If i understand correctly, that means in turn that i have to setup a tunnel for each host that should be reachable via the gateway, it that host does not fit into a network that can be assigned for an existing IPSEC tunnel.

          Mhh that will make things quite complex, because the hosts that should be reachable via that gateway, do not follow a pattern in terms of ipadresses, and it is beyond my reach to change them.

          As a workaround, would it be possible, to route any traffic from siteA to siteB using a subnet like 0.0.0.0/0 in the IPSEC Tunnel definition, and maintain a static route table only on siteB?
          If this is possible, how would the default route be handled? (default route vs. IPSEC subnet 0.0.0.0./0)

          1 Reply Last reply Reply Quote 0
          • W
            Wolfgang
            last edited by

            @hoba:

            …
            For parallel tunnels to work you have to use unique identifiers for both tunnels (add them at vpn>ipsec, presharde keys tab) instead of using my IP-Adress.
            ...

            Why do i need to setup the identifiers there? Why would it not be sufficant to setup the identifiers in the vpn tunnel definition: Phase 1 proposal (Authentication)/My identifier (where i can select my ipadress/fqdn/domainname etc).

            So what is the difference?
            and
            What to select in the "vpn tunnel definition/My identifier " , when setting up an unique identifier.

            1 Reply Last reply Reply Quote 0
            • H
              hoba
              last edited by

              Wouldn't it be bad if you just setup identifiers that te other end doesn't know of and access is always granted?  ;)

              Have a look at http://pfsense.com/mirror.php?section=tutorials/mobile_ipsec/ how to use identifiers. It's not your exact scenario but you just have to do some abstraction and make both ends use identifiers like shown in this tutorial for each of the parallel tunnels.

              1 Reply Last reply Reply Quote 0
              • W
                Wolfgang
                last edited by

                Thanks. I look into the this.

                Would do you think about the scenarion using 0.0.0.0 as a vpn subnet as described above?

                1 Reply Last reply Reply Quote 0
                • H
                  hoba
                  last edited by

                  This means that all traffic to the internet would be routed to the other location and exit to the internet there too. Something that you probably don't want as you then load the other location with additional up and downstream of the remote location.

                  1 Reply Last reply Reply Quote 0
                  • W
                    Wolfgang
                    last edited by

                    I need to come back to this again.
                    For some reasons it fails. It seems there are two issues:

                    No matter what i do, i get this error (even with one tunnel, however it works)
                    1.) racoon: WARNING: No ID match.

                    I did the following:
                    SiteA:

                    Tunnel Configuration:
                    Negotiation Mode: "agressive" (to allow seperate Identifiers for the seperate IPSec Tunnels)
                    Authentication type: "Pre-Shared Key" : key1
                    My Identifier: "Domain name" : SiteAvalue

                    Keys/Pre-Shared Keys:
                    Identifier: SiteBvalue
                    Pre-Shared Key: key1

                    SiteB:

                    Tunnel Configuration:
                    Negotiation Mode: "agressive" (to allow seperate Identifiers for the seperate IPSec Tunnels)
                    Authentication type: "Pre-Shared Key" : key1
                    My Identifier: "Domain name" : SiteBvalue

                    Keys/Pre-Shared Keys:
                    Identifier: SiteAvalue
                    Pre-Shared Key: key1

                    The idea:
                    -SiteA passes the Identifer to SiteB.
                    -SiteB looks up the identifer in Keys/Pre-Shared Keys and uses is. (so it uses the idetifer as an index to get the pre-shared key)
                    What i do not understand:
                    Why would i have to provide the pre-shared-key in the Tunnel definition, if both sites can lookup the key in "Keys/Pre-Shared Keys"?

                    2.) Even when using only one tunnel using the configuration to get access to the remote host via the gateway like described above

                    siteA subnet 192.168.1.0/24  to  siteB 10.0.0.24/32

                    no tunnel gets established.
                    It seems, that siteB does not like to terminate a VPN IPsec tunnel, if the network does not match the network configured for the lan.
                    (Note: the static route entry to the GW exists on siteB)

                    The pfsense versions are both the same: 
                    Version:1.0.1 built on Sun Oct 29 01:07:16 UTC 2006

                    Any ideas are welcome

                    Regards

                    Wolfgang

                    1 Reply Last reply Reply Quote 0
                    • J
                      jeroen234
                      last edited by

                      try upgrading to a newer version of pfsense
                      sins 29 oct there is changed and fixed a lot

                      1 Reply Last reply Reply Quote 0
                      • W
                        Wolfgang
                        last edited by

                        The current version is the one mentioned as can be seen here:
                        http://pfsense.blogspot.com/2006/10/101-released.html

                        Or do you mean the head version?

                        1 Reply Last reply Reply Quote 0
                        • H
                          hoba
                          last edited by

                          No, the one mentioned here: http://pfsense.blogspot.com/2007/01/102-beta-period-will-start-soon-5-9s.html

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