Creating a GRE Tunnel Between OpenWRT and pfSense

Following on from my previous post about building a IPsec tunnel between a Palo Alto firewall and a pfSense VM, I started trying to build a GRE tunnel between a OpenWRT router on my local network and the pfSense VM. Since GRE tunnels are unencrypted, it needs to traverse the IPSEC tunnel and not the internet! Nothing will stop you from running a GRE tunnel over the internet, but running unencrypted data over the internet is something you really do not want to do.

The main advantage of a GRE tunnel is that it has interfaces inside the tunnel. This means that you can easily route traffic over the tunnel and also run routing protocols over them. As noted in my previous post about building an IPsec tunnel, Policy Mode IPsec tunnels do not have interfaces inside the tunnel, and thus routing is much messier and routing protocols cannot be run over them. Routed IPsec Tunnels overcome this problem, but are not available in pfSense.

GRE support is available in OpenWRT since the Barrier Breaker RC3 release (August 2014). It’s very new and GRE tunnel configuration is not available via the UI so it’s not for the faint of heart. Indeed, while attempting to configure this I managed to break the LAN interface of my router and had to SSH back in over the internet to fix things, eventually resorting to wiping the configuration! pfSense has supported GRE for some time, but as with the previous post i’m using 2.2 Alpha.

As always, diagrams make everything easier! As you can see in the diagram, a GRE tunnel is established between the OpenWRT router and pfSense VM. As the tunnel is between 192.168.2.1 (OpenWRT) and 192.168.1.1 (pfSense) the traffic must traverse the encrypted IPsec tunnel. Of course, you will need the appropriate routes in place for the two hosts to communicate, but this is left as an exercise to the reader.

GRE tunnel over IPsec.

GRE tunnel over IPsec.

pfSense Configuration

First things first, configuring pfSense.

  1. Create a new GRE tunnel via Interfaces > (Assign) > GRE.
    1. Set Parent interface to LAN.
    2. Set GRE remote address to the address of the OpenWRT router (192.168.2.1)
    3. Set GRE tunnel local address to the tunnel’s inner IP on the pfSense side (192.168.250.2).
    4. Set GRE tunnel remote address to the tunnel’s inner IP on the other end (192.168.250.1). Set the netmask to 30, as the tunnel only has two IP addresses on it.
    5. Click Save.
  2. Create a new Interface for the GRE tunnel via Interfaces > (Assign) > Interface assignments. This step must be performed after creating the GRE tunnel, otherwise the Add option for a new interface will not be available.
    1. A new OPT interface will be created and the Network port should automatically select your new GRE tunnel. Manually select if not.
  3. Create a rule to permit traffic via Firewall > Rules > Your New Interface. Set the rule as you wish, a permit all rule may be the best place to start.

All done! If you start a tcpdump on the pfSense system, filtering for traffic to and from the GRE tunnel destination (192.168.2.1), you’ll see a fair amount of ICMP traffic. This is because pfSense has automatically added the other side of the tunnel as a gateway and is monitoring it’s accessibility and latency via ping.

OpenWRT Configuration

These instructions assume you’re comfortable accessing and configuring OpenWRT via SSH. If not, wait for GRE tunnels to get proper support in OpenWRT’s LuCI web GUI.

  1. Add the GRE tunnel and interface by editing /etc/config/interfaces. Use the following configuration as a template based on the previous diagram;

A quick explanation of the options;

  • mygre Interface – the GRE tunnel itself.
    • ipaddr – The local IP address to bind the tunnel’s source to. Not required, but without this I found tunnel traffic was attempting to go over the internet rather than via the LAN!
    • peeraddr – The remote IP address of the tunnel.
    • mtu – Maximum packet size for the tunnel. GRE has an encapsulation overhead and then also goes over the IPsec tunnel which also has an overhead! Setting the MTU to 1400 is a nice safe value, but could be increased further.
    • proto – The protocol of the interface. GRE in this case.
  • mygre_static Interface – The local interface inside the GRE tunnel.
    • proto – The protocol of the interface. Static in this case.
    • ifname – A name for the interface. The at symbol allows this static interface to refer to the tunnel interface.
    • ipaddr – The tunnel’s inner IP address on the OpenWRT side.
    • netmask – The tunnel’s netmask. A /30 netmask is 255.255.255.252.
  1. Install the required packages kmod-gre  and gre . This can be done on the LuCI interface via System > Software.
  2. Restart the networking daemon to bring up the new tunnel using /etc/init.d/network restart. You will briefly lose connectivity.

Done! Run an ifconfig to see if the new tunnel interface has been created. You should see a new gre-mygre interface. If you also run tcpdump filtering for traffic to and from the GRE tunnel destination (192.168.1.1) you should see the ICMP pings from the pfSense system and, hopefully, replies back from the OpenWRT router.

Attribution

This forum thread on the OpenWRT forums has been particularly helpful in getting this tunnel up and running. Until GRE tunnels are documented in more depth, it serves as a very useful starting point for configuring a GRE tunnel on OpenWRT, along with the mailing list entries linked from the thread.

Good luck!

You may also like...

3 Responses

  1. Etienne says:

    Hello,

    I want to create a gre tunnel in OpenWRT.

    If I modify the network.conf file, Luci shows “protocol unsupported” for the interface.

    Is it none-the-less ok?

  2. KingJ says:

    This is to be expected as the Barrier Breaker version of OpenWRT has no LuCI package to support GRE tunnels, hence the protocol unsupported error. So long as you’re comfortable configuring it via the command line this shouldn’t be a problem.

  3. Brenton says:

    I’ve been looking for a few vpn methods to try reduce hops in my complex WiFi network basically I have many OpenWRT routers at different locations all linked over using WiFi they all run OSPF so all OSPF zones have routes to each other. Currently my setup has

    R1 is my main router with a pppoe(ADSL) interface and runs an OpenVPN server. Each router that has clients connected directly to them have their own zone, subnet (192.168.x.y) and a VPN end point (10.10.0.x). Main router doesn’t need a VPN end point obviously.

    Internet (pppoe)> R1 (eth)> R2 (wifi)> R3 (wifi)> R4 (eth/wifi)> Clients
    Internet (pppoe)> R1 (eth)> R2 (wifi)> R5 (eth/wifi)> Clients
    Internet (pppoe)> R1 (eth)> (eth/wifi)> Clients

    So with a rough idea of how my complicated wifi network is set up we can tell that there are 2 hops from any client before getting to the internet excluding clients connected to the main router.

    Hop example: Client (hop1)> R4 VPN tunnel (hop2)> R1 > Internet

    traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 60 byte packets
    1  192.168.0.1 (192.168.0.1)  1.104 ms  1.238 ms  1.667 ms
    2  10.10.0.1 (10.10.0.1)  34.029 ms  49.485 ms  51.543 ms

    This means for any special services that require ports forwarded I must forward them twice. This brings me to my question.

    Can I make tunnels from R1(Main router) to all the other routers with clients connected but instead have a bridge device in each router br0(tap0, eth0.3, wlan0) to reduce the hop to 1?

    For the VPN software I was looking at Ipsec (strongswan) for a while and came across your GRE example. My needs are that the VPN packages required take up very little space, little CPU, encryption not required.

    I’d be really happy if you could perhaps write a howto regarding a gre-bridge linking 2 OpenWRT routers with 1 or 2 routers between. So the 2 OpenWRT routers that are linked have the same subnet VLANs can be used for the bridged routers with connected clients.

    If you do create a howto for this please email me a link, or if you have any ideas where i can start, thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *