While GRE and VPN tunnels both provide a method of connecting remote networks virtually, you are correct in the assumption that there are pros and cons with both.
With VPNS, the biggest advantage is that they provide a more secure way for site-to-site traffic to communicate over the internet which is a public space. VPN tunnels encrypts traffic that is sent across the link while GRE tunnels simply encapsulate the traffic before sending it over the link.
However, VPN tunnels come with several disadvantages as well. VPN configurations must include statically maintained access lists to identify traffic allowed through the tunnel. This can become a tedious process for larger networks. Discontinuous subnets require separate tunnels. VPNs do not create routable interfaces, which means certain actions that could be taken on other interfaces cannot be taken on VPN tunnels. Also, VPNs do not allow multicast traffic to pass, therefore dynamic routing protocols, such as RIP and OSPF, are no longer options to use across VPN.
GRE tunnels will allow for a way to get around VPN shortcomings. GRE tunnels have no limitation on the types of traffic which can traverse it. It can route multiple subnets without multiple tunnels. Also, it creates a routable interface and routing protocols can operate across it. However, as mentioned above, it is not very secure.
Many users merge both VPNs and GRE tunnels together as a way to provide the security of VPN without running into the limitations VPNs contain. This method is to configure GRE over IPSec VPN tunnels. This allows GRE tunnel traffic to traverse across the VPN tunnel and only creates a single IPSec association regardless of the subnets that need to get across. It also provides a way for routing updates to be sent.
More information regarding GRE tunnels and GRE over IPSec tunnels are available in the guides below.
GRE Tunnels in AOS - https://supportforums.adtran.com/docs/DOC-1715
GRE over IPSec in AOS - https://supportforums.adtran.com/docs/DOC-2310
Please do not hesitate to let us know if you have any further questions.
Thank you Noor!
One real life implementation example where GRE tunnels came in handy for me is as follows:
We had a situation where two divisions of the same larger corporation were sharing a MPLS CUG. The default route on the MPLS cloud was to Division 1. Both divisions utilized their own separate Internet connection to which branches off of the MPLS CUG sourced Internet. The difficulty came into play when we added Division 2 to the MPLS CUG. Default routing on the MPLS CUG was to Division 1, but I need to get Branch Office of Division 2 to HQ of Division 2. As long as it was internal corp traffic, I was fine because I could use static routes to get to where I need to go. For Internet based traffic, I would typically rely on the "default routes" go get me there, but couldn't do that in this place.
I implemented GRE tunnels from Branch Division B to HQ Dvision B. I wasn't concerned about security since this was a Private MPLS CUG. Essentially, the GRE tunnel became a point-to-point connection from each Branch B location back to HQ Branch B. I was then able to route default traffic to the other side of the GRE tunnel versus to the MPLS CUG gateway at a specific Branch B location. It worked very nicely.
Some challenges for the above implementation later popped up which dealt with QoS and being able to prioritize traffic within the GRE tunnel as it was being sent from HQ to the Branch. Bandwidth limitation is much easier on physical interfaces, but when you run a bunch of GRE tunnels through a physical interface as I'm doing at HQ Division B's egress point to the MPLS CUG, it created some challenges.
One advantage was I didn't need the EFP package on all the routers due to using GRE's where I would have if I had implemented IPSEC VPNs. The GRE tunnels did add processing overhead to the routers where I think separate engines are built into most Adtran routers for IPSEC VPN processing.