GRE with IPSEC and NAT

brandon.l.mac · January 2, 2018, 6:40pm

Hello there I’m new to network lessons and hope to find some great wisdom here to point me in the right direction. Everything I’m discussing and asking about is not in a production environment and is used for labs only for learning and testing purposes. Thanks in advance for your assistance and feedback.

I’m wanting to find out what the requirements are for setting up GRE with IPSEC behind NAT ? I have 2 locations for this setup using the same equipment 2 x Cisco Router 2811. I want to establish a tunnel between the 2 sites for the purpose of allowing the 2 sites to communicate and once I test and ensure I have a secure tunnel I will then want to build servers at each end to allow for the 2 sites to communicate with domain controllers one site will become the forest the other site will be a child domain. I’m relatively new to the GRE and IPSEC tunnel stuff so I’m trying to understand GRE with IPSEC vs IPSEC with GRE as I see these terms flipped a lot and was wondering if there is a difference in the setup configs and if they do different tasks or handle things differently? The configs shown below is just a brief example of the network I would like to configure and need assistance with getting started on the configs as I don’t understand where to place specific IPs in my configs as your example shows a network that looks like its all internal and in the same location as my 2nd router is offsite.
Question 1: How to configure GRE with IPSEC behind NAT?
Question 2: How to add additional security with ACL or filtering traffic on router because of the use with public IPs?
Question 3: Is this setup sufficient to handle the communication of Windows servers at each of the sites i.e replication, kerberos etc.
Question 4: What ports or protocols would you open on firewall to allow this connection? VPN 1723 ? IPSEC 50, 51, 500 ISAKMP?
Question 5: Is there a timeout time for how long the tunnel stays up or a way to force a reconnection if it does disconnect ?
Question 6: I see that you have implemented OSPF for the purposes of identifying the networks to on another after the tunnel is established is this correct? So Site A connects to Site B is just to establish a path but the networks that reside on each side are unknown to one another even with the tunnel?

RTR A (Site 1)
Outside INT Fa0/1
Public IP 25.2.2.2 (for discussion purposes)
IP nat outside
int fa0/0
ip nat inside
ip add 172.16.1.1 255.255.255.0

int tunnel 1
10.1.1.2 255.255.255.0

RTR B(Site 2)
Outside INT Fa0/1
Public IP 27.2.2.2
Ip nat outside 
INT Fa0/0
ip add 192.168.1.1 255.255.255.0
ip nat inside

int tunnel 1
10.10.1.1 255.255.255.0

ReneMolenaar · January 17, 2018, 2:19pm

Hello Brandon,

Welcome aboard Let me see if I can help you out.

There is a big difference yes. GRE is basically nothing more but a tunneling method where we put IP packets into other IP packets. You can see it nicely in this wireshark capture:

https://www.cloudshark.org/captures/368dcd1ddc06

IPsec is a framework that allows us to do authentication and/or encryption on the IP layer. For a detailed example of what can be authenticated and/or encrypted, take a look at this post:

Now the big question is, how do these two work together…is it IPsec over GRE or GRE over IPsec, etc.

The main reason that we use GRE in combination with IPSec is that IPSec is unable to do anything with multicast traffic. If you have two routers that are connected to the Internet and you somehow want to run a routing protocol like OSPF between them, you’ll need GRE to encapsulate the multicast traffic. Since GRE isn’t encrypted, we use IPSec to protect this traffic.

IPSec and GRE can work together in two ways:

You can configure a GRE tunnel and then encrypt the entire tunnel with IPSec.
You can encrypt traffic with IPSec and then tunnel it with GRE.

Option 1 is what we normally do when you want to exchange multicast traffic between two routers over the Internet. We call this GRE over IPSec. IPSec is the outer header. Here’s a configuration example for this option:

Option 2 is a bit more uncommon…IPSec over GRE means that we first encrypt our traffic with IPSec and then tunnel it through GRE. The outer header is then GRE. I don’t have a configuration example ready but you can do this by taking the example from option 1 and moving the crypto-map from the physical interface to the tunnel interface. The traffic will be encrypted IPSec first, then a GRE header is added.

About your questions:

Do you mean a router that is configured with IPSec/GRE that is sitting behind a NAT router? In the scenario you describe with the two routers it won’t be an issue since they both have a public IP address.

By default, all traffic is permitted so that might be something you want to restrict. If you use GRE over IPSec then you can use an ACL only to permit traffic from the router on the other side. Something like:

Extended IP access list ISAKMP_IPSEC
    10 permit udp host REMOTE_ROUTER_PUBLIC_IP any eq isakmp

You also want to do this for things like SSH. With regular standard or extended access-lists, it’s difficult to filter everything since it only permits or denies traffic based on a match with a single packet. It’s better to use something like reflexive access-lists or zone based firewall so that you can deny all inbound traffic with some exceptions for SSH/IPSec:

This depends if your traffic is routed or not and if it uses multicast traffic or not. Probably all traffic from Windows protocols can be routed. If you have traffic that has to be in the same broadcast domain (VLAN) then GRE or IPSec won’t work. I think some Windows applications might use multicast traffic so using GRE is a good idea.

For IPSec, you need UDP 500 for ISAKMP. ESP is protocol 50 and AH is protocol 51 (those are not port numbers). Port 1723 is PPTP so we don’t need that for IPSec.

GRE stays up as long as you have a tunnel interface and a source IP address. You can enable a keepalive so that it goes down once the remote end is unreachable. IPSec has different timers for phase 1 and phase 2.

With a GRE tunnel, the tunnel is just another (logical) interface. You still have to implement routing. First, you need something so that the two routers are able to reach each other’s tunnel destination address. In my labs, I often use OSPF or EIGRP but you can also use static routes. Once the tunnel is up, you need to route your traffic through the tunnel for any networks that you want to reach. With GRE, you can run a routing protocol like OSPF/EIGRP/RIP on the tunnel interface to achieve this.

In the encrypted GRE tunnel with IPSec lesson, I used static routes so that HQ/Branch can reach each other’s tunnel destination addresses. On the tunnel and loopback interfaces, we run OSPF.

Hope this helps!

Rene

brandon.l.mac · January 24, 2018, 6:14am

I’m having issues with my configs I keep going back to your post and videos and still can’t seem to figure out where the issue is at?? Sorry for the long post with my configs I don’t see a code button either like the panel says for writing on here so not sure how to do that .

I believe NAT is causing problems with my configs I can’t seem to establish a connection.

RTR1
int fa0/1
desc  router to ISP PUBLIC IP
ip add 6.6.6.6
ip nat outside
ip access-group 110 in

int fa0/0.28
desc inside int vlan 28 
ip add 10.0.0.1 255.255.255.0
ip nat inside

int tunn 1
ip add 192.168.1.1 255.255.255.0
ip nat inside
 ip mtu 1400
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1360
 keepalive 10 3
 tunnel source FastEthernet0/1
 tunnel destination 5.5.5.5

ip nat inside source list 110 int fa0/1 overload
access-list 110 permit gre host 5.5.5.5 host 6.6.6.6
access-list 110 permit ip any any

ip route 0.0.0.0 0.0.0.0 6.6.6.6
ip route 192.168.1.0 255.255.255.0 192.168.1.2


RTR2
int fa0/1
desc  router to ISP PUBLIC IP
ip add 5.5.5.5
ip nat outside
ip access-group 110 in

int fa0/0.10
desc inside int vlan 10
ip add  192.168.10.1 255.255.255.0
ip nat inside 


int tunn 1
ip add 192.168.1.2 255.255.255.0
ip nat inside
 ip mtu 1400
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1360
 keepalive 10 3
 tunnel source FastEthernet0/1
 tunnel destination 6.6.6.6

ip nat inside source list 110 int fa0/1 overload

ip route 0.0.0.0 0.0.0.0 5.5.5.5
ip route 192.168.1.0 255.255.255.0 192.168.1.1
access-list 110 permit gre host 6.6.6.6 host 5.5.5.5
access-list 110 permit ip any any

ReneMolenaar · January 24, 2018, 8:00pm

Hi Brandon,

It’s the preformatted text button in the editor:

2018-01-24_20-39-45

Or you can select your text and use the keyboard shortcut CTRL+SHIFT+C to format the text as code. It looks a bit cleaner

About your config, there’s a couple of things I see:

Take a close look at your static routes. On R1 you have:

ip route 192.168.1.0 255.255.255.0 192.168.1.2

This route means "if you want to go to 192.168.1.0 /24, go to 192.168.1.2. This doesn’t make sense because:

192.168.1.2 belongs to the 192.168.1.0 /24 subnet. That’s like telling the router that if you want to go to X, you have to go X
You only need static routes for remote subnets. 192.168.1.0/24 is directly connected for your router, it’s on your tunnel interface.

You probably try to reach the remote network on R2? The 192.168.10.0 /24 network? You’ll need a static route like this:

ip route 192.168.10.0 255.255.255.0 192.168.1.2

This basically means "If you want to go to 192.168.10.0 /24, go to 192.168.1.2 (the other side of the tunnel)

And on R2 you need something similar to reach the network you have on R1.

The second thing you need to check is your NAT configuration:

ip nat inside source list 110 int fa0/1 overload
access-list 110 permit gre host 5.5.5.5 host 6.6.6.6
access-list 110 permit ip any any

I’m guessing the second permit ip any any statement you tried for testing? Right now it’s translating everything.

You also don’t need the first line. It’s telling the route to translate all GRE traffic between 5.5.5.5 and 6.6.6.6 and that’s something we don’t need. If these were real routers that are connected to the Internet then 5.5.5.5 and 6.6.6.6 are public IP addresses, we don’t need to translate these.

What you do have to translate is traffic from your private IP addresses going out to the Internet. For example, your 10.0.0.0 /24 network needs translation when it goes out to the Internet. You can use an access-list like this:

ip access-list extended NAT
deny ip 10.0.0.0 0.0.0.255 192.168.10.0 0.0.0.255
permit ip 10.0.0.0 0.0.0.255 any

The first deny rule is there because we don’t want to translate LAN-to-LAN traffic that goes through the GRE tunnel. The second permit statement permits all traffic from 10.0.0.0 /24 to any other destinations.

When testing, be careful with your ip access-group 110 in on your interfaces. It’s best to test things first, make sure they work…then add access-lists to deny/permit certain traffic.

You have a lot of things going on in the config of these routers. GRE, NAT, Access-lists. When troubleshooting something like this…take it step by step:

First configure a GRE tunnel, see if you can ping the source/destination tunnel addresses.
Then try if you can ping through the tunnel to remote networks. If not, check your routing.
Then try adding NAT, test everything you configured previously.
Then add access-lists to block unwanted traffic.

Hope this helps!

Rene

brandon.l.mac · January 24, 2018, 8:47pm

Rene,

Thanks so much again. The ip route for static routing I’m not sure I’m following you on this even though you explained it and now I realize there was an error. So in the mistake I made with pointing X to X to get to the other side what if the configs were

RTR1 
int tunnel 1
192.168.1.1 255.255.255.252
RTR 2
192.168.1.2 255.255.255.252

ip route 192.168.1.2 255.255.255.255 192.168.1.1

?? would this work or still not be correct?

IP NATTING this is the part that really throws me. The routers are real and connected with public ip addresses. However, the network is being natted for the rest of the traffic that is being passed so maybe that is a missing element in this situation i need to disclose. Could I not use the public IP to nat the private traffic outside to the internet as well as pass the GRE tunnel traffic? Would this be different to configure ?

Yes, the any any statement is for testing indeed because there was no GRE traffic being passed.

Not following the ip access-list extended NAT
deny statement so is this denying the inside ip address for example on my sub-int passing over a vlan ? Then you go back and allow the 10 network to pass any traffic to any where from the way I understand the statement. I thought the deny statement would override this because its denying the same 10 network. Essentially I want to pass all traffic from my DC thru the tunnel to the other side so if that network was

172.16.1.0 /24 and the other side inside network is 10.1.0.0 /24

ip access-list extended NAT
deny ip 172.16.1.0 0.0.0.255 10.1.0.0 0.0.0.255  
permit ip 172.16.1.0 0.0.0.255 any

I don’t see how this allows traffic to pass if the statement above denies the same network to pass traffic to the other side across the tunnel ?

brandon.l.mac · January 26, 2018, 5:23am

Rene,

Great news with all your awesome support and tips on what I should look at I have now established my tunnel from site to site behind NAT. Now 2 questions implementing IPSEC and actually pointing specific device to route traffic over the tunnel as when I’m doing a sh ip nat trans I don’t see any GRE traffic being passed. Also if I set an ip host to host to pass all traffic thru the tunnel how would I do this and where would I put it in the configs under the gre ACL or the NAT ACL ??

Also now that GRE with NAT is setup how would I go about pushing IPSEC onto each of the routers do I have to change any of the routing information because IPSEC has to encrypt the tunnel traffic is how it works right ??

Thanks for all your assistance

ReneMolenaar · January 28, 2018, 12:49pm

Hi Brandon,

About this static route:

You don’t need this and here’s why:

If you configure an IP address and a subnet mask on an interface, your router also know what subnet is attached to the interface. Do a “show ip route connected” and you’ll see this. It knows that the 192.168.1.0/30 subnet is on your tunnel interface so there is no need to add a static route for the remote tunnel address. You only need a static route for networks you want to reach that are on the other side. For example:

ip route 2.2.2.0 255.255.255.0 192.168.1.2

If you want to reach 2.2.2.0/24 through 192.168.1.2.

The only traffic that you need to translate with NAT is traffic from your private IP addresses going to the Internet. For example, a host with IP address 192.168.1.1 going to 8.8.8.8 (google DNS). You don’t have to translate traffic that goes through the GRE tunnel since the GRE tunnel is encapsulating the original IP packet. The GRE header has public source/destination addresses so those are routable.

In this access-list:

ip access-list extended NAT
deny ip 172.16.1.0 0.0.0.255 10.1.0.0 0.0.0.255  
permit ip 172.16.1.0 0.0.0.255 any

Access-lists are processed top to bottom and if there is a match, it doesn’t check for other matches. A packet from 172.16.10.0/24 going to 10.1.0.0 /24 is denied, which means we don’t translate it with NAT.

All other traffic from 172.16.1.0/24 going to anywhere else will be NAT translated.

We use this rule to prevent traffic between 172.16.10/24 and 10.1.0.0/24 to be translated. It doesn’t have to be translated since is goes through the GRE tunnel.

For your GRE traffic, forget about NAT for now…to get traffic through your GRE tunnel the only thing you need is routing. For example, on R1 you need:

ip route 192.168.10.0 255.255.255.0 192.168.1.2

Which tells R1 that if it wants to reach 192.168.10.0/24, it has to go to 192.168.1.2 (the other end of the tunnel). You need a similar static route on R2 for the LAN network you have on R1.

Once you added those static routes, and your GRE tunnel is working, then you can ping from one side to the other. Once that works…then try adding NAT for your non-GRE traffic.

And once that works, you can try adding IPSec and encrypt the GRE tunnel