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

    Static route to GRE destination

    2.0-RC Snapshot Feedback and Problems - RETIRED
    3
    6
    7.8k
    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
      casper4242
      last edited by

      Hi there,

      I've set up a GRE tunnel between a 2.0-snapshot  of yesterday and a remote cisco. I've also added an interface for it with type "none" so I could add firewall rules to that tunnel (otherwise all incoming packets were dropped).
      However… how do I now assign a static route (or multiple) that point to the target of that tunnel? In the static routes section, the interface doesn't appear because it's not treated as a gateway. If  I define the interface as type "static" instead of "none", using the same IP address as in the gre definition page, the interface doesn't get any ip address at all when I check in the CLI.

      I would actually like to have two tunnels, and route over the tunnels in an active/fallback scenario, so I could use the features already there for "normal" gateways. Is this at all possible?

      Cheers,
      Markus

      PS: after many fruitless hours I've for the moment given up on having that tunnel ipsec encrypted...

      1 Reply Last reply Reply Quote 0
      • _
        _igor_
        last edited by

        So I'm interested too in geting that thing running. If anywhere can clear this a bit please…

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by

          You create a gateway for the GRE interface with the other peer as destination.

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

            Hm, perhaps I have a misunderstanding of how GRE tunnels are supposed to be setup with pfsense.
            My current understanding comes from the way Cisco does things, and perhaps it would help if someone
            could explain how the following scenarios translate into pfsense GRE support:

            a) point-to-point, numbered

            Router-A:

            interface tunnel0
                  ip address {ATIP} {NM-TIP}
                  tunnel source {ATSIP}
                  tunnel destination {BTSIP}
                  tunnel mode gre ip

            Router-B:

            interface tunnel0
                  ip address {BTIP} {NM-TIP}
                  tunnel source {BTSIP}
                  tunnel destination {ATSIP}
                  tunnel mode gre ip

            with {ATIP} and {BTIP} in the same network (being the actual interface address of the tunnel)
                and {ATSIP} and {BTSIP} being the respective tunnel endpoint addresses, which are usually
                the IP addresses of a local interface on that router.

            b) point-to-point, unnumbered

            Router-A:

            interface tunnel0
                  ip unnumbered {ALIF}
                  tunnel source {ATSIP}
                  tunnel destination {BTSIP}
                  tunnel mode gre ip

            Router-B:

            interface tunnel0
                  ip unnumbered {BLIF}
                  tunnel source {BTSIP}
                  tunnel destination {ATSIP}
                  tunnel mode gre ip

            with {ALIF} and {BLIF} being local interfaces of router A and B, respectively.

            c) multipoint

            these use "tunnel mode gre multipoint", which I guess is not supported by the FreeBSD gre interface ?

            I tried to put these the following way into pfsense configuration sections. Since pfsense wants specific
            addresses for the tunnel, I concluded that it's modelling its configuration after type a) above:

            Firewall: GRE: Edit

            Parent interface:                  interface with IP {ATSIP}
                  GRE remote address:            {BTSIP}
                  GRE tunnel local address:    {ATIP}
                  GRE tunnel remote address: {BTIP} [pfx of {NM-TIP}]

            this by itself creates a proper gre0 interface:
                  gre0:  flags=…
                    tunnel inet {ATSIP} --> {BTSIP}
                    inet  {ATIP} --> {BTIP} netmask {NM-TIP}

            however, this gre0 can't be used yet in the rule base or as gateway, so a pfsense interface
                has to be created as well. So, I create a new interface (OPT1). If I set its type to "None", and
                manually add it as a gateway later (with {BTIP} as the gateway address), the interface now
                looks like this:
                  gre0:  flags=...
                    tunnel inet {ATSIP} --> {BTSIP}

            it has lost its own interface address, and I also don't have a manual route entry for {BTIP} in
                the routing table. So this is clearly wrong.

            I then set it to type "static", specified {ATIP}/{NM-IP} as the IP address, and defined a gateway
                of {BTIP} for the interface.  However, the gif0 interface still didn't regain its address:
                  gre0:  flags=...
                    tunnel inet {ATSIP} --> {BTSIP}

            nor are there route entries for {BTIP} (or {ATIP}).

            So, is this a pfsense bug, or a misunderstanding on my part of how things should be setup ?

            Thanks,
            Markus

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Upgrade to a snapshot later than this post and just leave the type to none on the assigned interface.
              Though you will need to enter the gateway manually too.

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

                Thanks! Snapshot of today fixes the issues, GRE including static route is up and running!

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