Hey all,

I know that it's possible to run GRE over and IPsec tunnel but I am
wondering if anyone here has seen some good documentation (besides the man
pages) or a howto on setting this up. I'm trying to config my OpenBSD
4.0firewall to interop with a route-based VPN network with a mix of
Fortigate
and Netscreen firewalls. Fortigates and Netscreens both use GRE interaces as
"tunnel interfaces" when creating route-based VPN tunnels. Right now all
endpoints are using un-numbered (0.0.0.0/0) GRE interfaces and so I would
like to use a similar configuration on the OpenBSD side but I am just
wondering how to accomplish this as I am uncertain how to bind the GRE
interface to a tunnel.

Right now I have a hub-and-spoke VPN network using static routes to route
traffic across the VPN. Each spoke endpoint has a static destination route
of 10.1.0.0/16 which is sent over GRE interface. The only exception to the
hub-and-spoke VPN is my OpenBSD firewall which I have to create VPN tunnels
to every spoke network I need access to (quite painfull). On my OpenBSD box
I would like to be able to use a single static destination route of
10.1.0.0/16 to send this traffic over a GRE interface to get to the rest of
the VPN network. Here's a snippet of the hub-and-spoke VPN network:

1.1.1.1
----------------
OpenBSD
10.1.1.0/24
----------------
    |
    |
    |
    |
2.2.2.2
----------------
Fortigate (Hub)
10.1.2.0/24
----------------
    |
    |
    |
    |
3.3.3.3
----------------
Juniper
10.1.3.0/24
----------------

Thanks in advance for your help.

Cheers,
-Chris

[ message continues ]

I ran into some kernel panics (watchdog reset) with GRE + ESP/Transport
(or ESP+GRE) back in the day.  It was related to MTU assumptions etc.
There was a sendbug(8) related to it.   Google "seklecki gre ipsec
openbsd"

http://archives.neohapsis.com/archives/openbsd/2006-01/0623.html

etc...



[ message continues ]

Hello Cris,

  GRE is standard and works in OpenBSD as RFC says ;-)

  When I was running gre over ipsec tunnel between two openbsd boxes
  (OpenBSD 3.8 or sth like that) it worked without any problems.
  but it works till now, so example from config of that machine (ip
  changed):
  
vpn1# cat /etc/hostname.gre0
1.1.1.1 2.2.2.2.netmask 0xffffffff carp0
!ifconfig gre0 tunnel 1.1.1.1 2.2.2.2
!route add -inet 192.168.1.0/24 2.2.2.2

  few things you should be aware of:
  a) sysctl.conf (net.inet.gre.allow=1, net.inet.ip.mtudisc=1)
  b) MTU - gre is "taking" 24 bytes from frame (i.e. 1476 from 1500
     bytes)
  c) IPSec uses DF bit - if you don't remember about that you can get
     into windowing problem (ethernet uses 1500 bytes and can't be
     splitted into fragments because of don't fragment bit)
  d) use different ip address space for your vpn-routers/concentrators
     and for your local networks. If you get blank paper and try to draw
     that (with OSI model in mind) you will make it in a few minutes :-)

  Good luck :)
  
-- 
Sylwester S. Biernacki <obeer@obeer.com>
X-NET, http://www.xnet.com.pl/

[ message continues ]

Chris Jones writes:
 > .... Fortigates and Netscreens both use GRE interaces as
 > "tunnel interfaces" when creating route-based VPN tunnels.

FortiGates do not use GRE interface when creating route-based VPN tunnels.
The route-based VPN on a FortiGate creates packets that are identical
to IPsec tunnel mode i.e. IP|ESP|IP.  As far as I'm aware, Netscreen do
the same.  Are you sure you don't have any Cisco's in your network?
They use GRE for IPsec unless you've got a farily recent version of
IOS that supports the virtual interface approach.


 > Right now I have a hub-and-spoke VPN network using static routes to route
 > traffic across the VPN. Each spoke endpoint has a static destination route
 > of 10.1.0.0/16 which is sent over GRE interface. The only exception to the
 > hub-and-spoke VPN is my OpenBSD firewall which I have to create VPN tunnels
 > to every spoke network I need access to (quite painfull). On my OpenBSD box
 > I would like to be able to use a single static destination route of
 > 10.1.0.0/16 to send this traffic over a GRE interface to get to the rest of
 > the VPN network.

Since the FortiGate doesn't use GRE for IPsec (unless you configured
it for some reason) then there is no need to use GRE on OpenBSD.  Just
define a normal tunnel based IPsec connection (as if the other end was
another OpenBSD box).  If you really want an interface so that you can
route over it, then you'd have better luck with a gif interface.  In
that case if you can get the tunnel to come up you could run
RIP/OSPF/iBGP on the OpenBSD gif interface and on the FortiGate IPsec
interface and not use static routing at all.

[ message continues ]

I may have been mistaken. I just pulled this information from this document
which Gregory Lebovitz from Netscreen co-authored back in 2003. On page 46
he talks about using GRE to create a virtual routing interfaces AKA tunnel
interface. I have configure route-based VPNs between a Netscreen and
FortiGate which interop just fine, which leads me to believe that they are
using the same approach to tunnel interfaces.

I have yet to get this to work between an OpenBSD box and a
FortiGate/Netscreen. I will look into the gif option to see if this will
work.

-Chris


[ message continues ]

This link would probably help ;)

http://www.isi.edu/div7/presentation_files/dynamic_routing.pdf


[ message continues ]

Chris Jones writes:
 > I may have been mistaken. I just pulled this information from this document
 > which Gregory Lebovitz from Netscreen co-authored back in 2003.

No FortiGate model supported GRE in 2003, it wasn't added until 2006.

 > On page 46 he talks about using GRE to create a virtual routing
 > interfaces AKA tunnel interface. I have configure route-based VPNs
 > between a Netscreen and FortiGate which interop just fine, which
 > leads me to believe that they are using the same approach to tunnel
 > interfaces. 

They are using the same approach, it just isn't GRE based.  Both
FortGate and Netscreen allow you to define a IPsec interface which has
the routing benefits described in
http://www.isi.edu/div7/presentation_files/dynamic_routing.pdf 
but which is also compatible with anything that supports tunnel mode
IPsec.


 > I have yet to get this to work between an OpenBSD box and a
 > FortiGate/Netscreen. I will look into the gif option to see if this will
 > work.

It isn't clear to me why you don't just use tunnel mode IPsec on
OpenBSD, it is compatible with both FortiGate and Netscreen.  The gif
approach is going to be a problem unless you have an IKE daemon that
can negotiate tunnel mode (because that's what the FortiGate will
expect) but actually use tranport+IPIP as per the RFC draft referenced
in the above.

[ message continues ]

interesting; if my understanding of this and the RFC that the referenced
'touch' draft was published as (rfc3884), at one end you can configure one
side in *transport* mode carrying ipip encapsulated packets - gif(4) with
net.inet.ipip.allow=1, afaict - and the other side in tunnel mode as usual.

this could be useful for either running routing protocols over IPsec, or
for redistributing IPsec "routes" into an IGP (the latter being something
I've been wondering about how to handle in some way that's a little more
flexible than "configure all of concentrator X's tunnels within 10.X/16
and all of concentrator Y's tunnels within 10.Y/16...)

[ message continues ]

Stuart Henderson writes:
 > interesting; if my understanding of this and the RFC that the referenced
 > 'touch' draft was published as (rfc3884), at one end you can configure one
 > side in *transport* mode carrying ipip encapsulated packets - gif(4) with
 > net.inet.ipip.allow=1, afaict - and the other side in tunnel mode as usual.

That's the idea, though the IKE daemon on the transport+IPIP side has
to actually offer tunnel mode or the other end will typically reject
the negotiation.


 > this could be useful for either running routing protocols over IPsec, or
 > for redistributing IPsec "routes" into an IGP (the latter being something
 > I've been wondering about how to handle in some way that's a little more
 > flexible than "configure all of concentrator X's tunnels within 10.X/16
 > and all of concentrator Y's tunnels within 10.Y/16...)

It is useful for all of the above.

[ message continues ]

I've been setting up IPSEC tunnels with Juniper/NetScreen firewalls for 
years. I've never done GRE. I have setup a simple tunnel with 
Juniper/NetScreen to OpenBSD. I didn't use GRE. I don't see why you need 
GRE since IPSEC does tunnels.

[ message continues ]