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

Static route to GRE destination

Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
6 Posts 3 Posters 7.9k 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.
  • C
    casper4242
    last edited by May 22, 2010, 2:32 PM

    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 May 23, 2010, 6:39 PM

      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 May 24, 2010, 7:29 AM

        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 May 25, 2010, 9:21 PM

          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 May 25, 2010, 10:25 PM

            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 May 27, 2010, 1:15 PM

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

              1 Reply Last reply Reply Quote 0
              6 out of 6
              • First post
                6/6
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                This community forum collects and processes your personal information.
                consent.not_received