Building an IPSEC GRE Tunnel

So there is a little bit of confusion on the interwebz when it comes to understanding an IPSEC GRE tunnel. First off lets look at how it actually works.

GRE works by encapsulating IP traffic inside of an IP packet and sends it across the wire to its destination where it is decapsulated and the inner-packet is than routed. GRE is commonly used to bridge two routed domains over a network outside of your administrative control.

When using GRE over the public internet, security is a concern and therefore you would want to encrypt the traffic, this is where IPSEC comes in.

IPSEC GRE tunnels are GRE tunnels that are encapsulated inside of an IPSEC payload and sent across a public network. If you were to capture such traffic using Wireshark you would see only ESP (Encapsulating Security Payload) and not GRE as depicted below;

To get a better understanding this concept the following diagram should help;

Okay so how do I configure it?

Now on to the fun part, configuration. First off lets take a look at the diagram we’ll be using to demonstrate this technology;

The following configuration demonstration was performed on the Stub Lab. If you like, you can also do this configuration on the Stub Lab which is a freely accessible Cisco Lab. All ya gotta do is sign up and reserve lab time!

First off we need to configure the INET router. This router will simulate the internet connectivity between the NYC and ATL routers. The following initial configuration has been provided to make this quickly achievable;

!####################################!# IPSEC GRE TUNNEL - INET ROUTER #!####################################!enableconfigure terminal!hostname INETno ip domain-lookup!interface Serial0/0/0 description Link to R2 Se0/1/0 ip address 198.51.100.33 255.255.255.252 no fair-queue no cdp enable no shut!interface Serial0/1/0 description Link to R1 Se0/0/0 ip address 203.0.113.129 255.255.255.252 no cdp enable no shut!interface FastEthernet0/0 shutdown!interface FastEthernet0/1 shutdown!line con 0 logging sync no exec-timeout!end

Now we can go ahead and configure the basics on the NYC and ATL routers. We’ll setup a loopback interface on each router to simulate LAN connectivity and than EIGRP to route over the tunnel.

Router con0 is now availablePress RETURN to get started.Router>enableRouter#config terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)#hostname NYCNYC(config)#no ip domain-lookupNYC(config)#interface Loopback0NYC(config-if)#description Simulated LAN ConnectionNYC(config-if)#ip add 10.1.0.1 255.255.255.0NYC(config-if)#exitNYC(config)#interface Serial0/0/0NYC(config-if)#description Link to InternetNYC(config-if)#ip address 203.0.113.130 255.255.255.252NYC(config-if)#exitNYC(config)#router eigrp 1NYC(config-router)#no auto-summaryNYC(config-router)#network 10.1.0.1 0.0.0.0NYC(config-router)#exitNYC(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.129NYC(config)#Router con0 is now availablePress RETURN to get started.Router>enableRouter#config terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)#hostname ATLATL(config)#no ip domain-lookupATL(config)#interface Loopback0ATL(config-if)#description Simulated LAN ConnectionATL(config-if)#ip add 10.2.0.2 255.255.255.0ATL(config-if)#exitATL(config)#interface Serial0/1/0ATL(config-if)#description Link to InternetATL(config-if)#ip address 198.51.100.34 255.255.255.252ATL(config-if)#exitATL(config)#router eigrp 1ATL(config-router)#no auto-summaryATL(config-router)#network 10.2.0.2 0.0.0.0ATL(config-router)#exitATL(config)#ip route 0.0.0.0 0.0.0.0 198.51.100.33ATL(config)#

Now that the basic config is out of the way we can now setup the basic GRE tunnel interface and enable EIGRP routing on the tunnel interface which should allow the two simulated LAN segments to communicate with each other unencrypted over the public internet.

NYC(config)#interface Tunnel0NYC(config-if)#description IPSEC GRE TUNNEL TO ATLANTANYC(config-if)#ip address 10.12.0.1 255.255.255.0NYC(config-if)#tunnel source Serial0/0/0NYC(config-if)#tunnel destination 198.51.100.34NYC(config-if)#exitNYC(config)#router eigrp 1NYC(config-router)#network 10.12.0.1 0.0.0.0NYC(config-router)#exit%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.12.0.2 (Tunnel0) is up: new adjacencyNYC(config)#exitNYC#%SYS-5-CONFIG_I: Configured from console by consoleNYC#ATL(config)#interface Tunnel0ATL(config-if)#description IPSEC GRE TUNNEL TO ATLANTAATL(config-if)#ip address 10.12.0.2 255.255.255.0ATL(config-if)#tunnel source Serial0/1/0ATL(config-if)#tunnel destination 203.0.113.130ATL(config-if)#exitATL(config)#router eigrp 1ATL(config-router)#network 10.12.0.2 0.0.0.0ATL(config-router)#exit%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.12.0.1 (Tunnel0) is up: new adjacencyATL(config)#exitATL#%SYS-5-CONFIG_I: Configured from console by consoleATL#

Now that a basic GRE tunnel has been established, we can verify the operational status of the tunnel by pinging the other end.

NYC#ping 10.12.0.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.12.0.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 msNYC(config)#

Also you should have noticed that the NYC and ATL became EIGRP neighbors and you should now have the ability to ping Atlanta’s simulated LAN segment from New York as demonstrated below;

NYC#ping 10.2.0.2 source loopback0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.2.0.2, timeout is 2 seconds:Packet sent with a source address of 10.1.0.1 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 msNYC#

Now we’re ready to configure the IPSEC portion of the IPSEC GRE tunnel. First you must define an ISAKMP policy. ISAKMP policies are used to define the phase 1 negotiations of an IPSEC tunnel. When it comes to IPSEC GRE, the ISAKMP policy is very simple. The policy must be defined on both routers.

NYC#config terminalNYC(config)#crypto isakmp policy 10NYC(config-isakmp)#authentication pre-shareNYC(config-isakmp)#exitNYC(config)#ATL#config terminalATL(config)#crypto isakmp policy 10ATL(config-isakmp)#authentication pre-shareATL(config-isakmp)#exitATL(config)#

Next we need to need to define the pre-shared key on a per peer basis;

NYC(config)#crypto isakmp key 0 CISCO address 198.51.100.34ATL(config)#crypto isakmp key 0 CISCO address 203.0.113.130

than we need to configure the transform-set which will actually be used to encrypt the data. For this demonstration we’re going to use AES128 and SHA hashing.

NYC(config)#crypto ipsec transform-set TRANS_IPSEC_GRE esp-aes esp-sha-hmac ATL(config)#crypto ipsec transform-set TRANS_IPSEC_GRE esp-aes esp-sha-hmac

Next we’ll need to build the ipsec profile that will be applied to the GRE tunnel interface;

NYC(config)#crypto ipsec profile IPSEC_GRENYC(ipsec-profile)#set transform-set TRANS_IPSEC_GREATL(config)#crypto ipsec profile IPSEC_GREATL(ipsec-profile)#set transform-set TRANS_IPSEC_GRE

Finally once all the IPSEC configuration is completed we can assign the IPSEC profile to the tunnel interface as shown below;

NYC(ipsec-profile)#interface Tunnel0NYC(config-if)#tunnel protection ipsec profile IPSEC_GRENYC(config-if)#%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ONNYC(config-if)#^ZNYC#ATL(ipsec-profile)#interface Tunnel0ATL(config-if)#tunnel protection ipsec profile IPSEC_GREATL(config-if)#%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ONATL(config-if)#^ZATL#

And now for the ultimate verification! We’ll ping the Atlanta simulated LAN segment (Loopback0: 10.2.0.2) from the NYC simulated LAN Segment (Loopback0: 10.1.0.1) and verify that the packets are being encrypted and decrypted by viewing the ipsec security-association;

NYC#ping 10.2.0.2 source loopback0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.2.0.2, timeout is 2 seconds:Packet sent with a source address of 10.1.0.1 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 msNYC#NYC#show crypto ipsec sa peer 198.51.100.34interface: Tunnel0 Crypto map tag: Tunnel0-head-0, local addr 203.0.113.130 protected vrf: (none) local ident (addr/mask/prot/port): (203.0.113.130/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (198.51.100.34/255.255.255.255/47/0) current_peer 198.51.100.34 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 79, #pkts encrypt: 79, #pkts digest: 79 #pkts decaps: 79, #pkts decrypt: 79, #pkts verify: 79 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 203.0.113.130, remote crypto endpt.: 198.51.100.34 path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0 current outbound spi: 0xE15A5BAE(3780795310) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x67D027CC(1741694924) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2007, flow_id: NETGX:7, sibling_flags 80000046, crypto map: Tunnel0-head-0 sa timing: remaining key lifetime (k/sec): (4590179/3282) IV size: 16 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xE15A5BAE(3780795310) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2008, flow_id: NETGX:8, sibling_flags 80000046, crypto map: Tunnel0-head-0 sa timing: remaining key lifetime (k/sec): (4590178/3282) IV size: 16 bytes replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas:NYC#

We have successfully build an IPSEC GRE tunnel that can route EIGRP between two locations over the internet securely. Post your comments and questions below!

اكمل القراءة

• twitter
• share
• plus

Private Internet Access via L2TP IPSEC Cisco IOS Client

So with the NSA, the CIA and the FBI sucking up every bit they possibly can on the internet at countless locations around the world you wonder how could you possibly become anonymous on the interwebz? Of course it’s not just the United States Government that feels the need that you as an individual should sacrifice your liberty for security, this practice is becoming quite common all around the globe from the United Kingdom all the way down under in the land of the happy kangaroos (Australia of course). Just for the record I’m sure the kangaroo’s don’t give a shit because they don’t feel their privacy is violated.

As the world awakens to the vast over reach of Government around the globe people are looking for new and innovative ways to retain and/or regain their privacy. As a network engineer I wanted to share one of many methods I use to remain anonymous on the internet.

So first lets ask a big question. Why would you want to remain anonymous on the internet? Think about that for a minute.

As a network engineer or an individual aspiring to become a network engineer you will quickly realize or learn that you can easily be singled out on the internet with just an IP address. Your IP Address can be used to locate you geographically speaking.

For example lets say your computer is infected with a virus and you become an unwilling participate in a hack that is orchestrated by individuals attempting to gain access into classified computer networks to gather information. You personally would be held responsible, after all it is your IP Address that is doing the hacking. Your IP address along with the date and time included in subpoena sent to your ISP could easily identify you and the home address related to the service. Next thing you know you have the SWAT team busting your door down while you’re watching reality TV of SWAT teams busting peoples door down. How is that for irony?

So how do you solve this problem? Through the use of VPN technology. There are several VPN providers on the internet who’s sole purpose is to provide anonymity online. You pay for the service and they provide you with the credentials to connect to a VPN. After you’ve connected all your internet traffic traverses their network and any internet request that are made are made through the VPN. So now your public IP Address is not the IP Address provided to you by your ISP which can be used to identify you but rather the public IP address used by the anonymous VPN service.

While using Anonymous VPN services can be used to commit illegal crimes such as downloading and distributing copyrighted material or perhaps even other nefarious actions, Free CCNA Workbook does not promote or endorse any of these actions. With that being said anything you do on anonymous vpn services is at your own risk.

Beyond the Basics

Traditionally anonymous VPN services are typically used via Dialer interfaces on common operating systems such as Windows and Linux. While this configuration works, it only works for a single PC unless you want to configure a Windows Server with connection sharing which of course is a huge pain in the @$$.

Using a Cisco IOS router you can than allow multiple PC’s to use the VPN service by changing the default gateway on the PC(s) to the inside interface of the VPN Client. You can even go a step further by setting up a separate SSID on your wireless access point(s) so that you have a dedicated wireless SSID which only uses the anonymous VPN service as its connection to the internet.

There are tons of Anonymous VPN Providers out there however this blog is going to demonstrate the configuration of an L2TP IPSEC using Private Internet Access

So enough with all the jibble jabble lets dive in to the config shall we?

The L2TP IPSEC Tunnel Configuration

Well I’m not going to explain every single line of configuration however if you are experienced enough in Cisco IOS and VPN technologies this should all make sense. If you have questions you can post a comment with your question.

Before you get started you’re going to need the credentials for your VPN Authentication. The credentials you got in your email when you signed up with Private Internet Access is NOT the credentials you’ll be using to connect to the VPN. You must log into the Client Support Page and generate new vpn credentials which will be used. Once you have the credentials you’ll need the peer IP address which you’ll be connecting to.

You can obtain this by pinging the DNS name of the VPN gateway you wish to connect to. In this case we’re going to use East US Gateway “us-east.privateinternetaccess.com” At the time of this blog this name resolves to 108.61.152.251. This of course will probably change by the time you read this.

Once you have all this information you’re ready to start configuration. Go ahead and configure hostname, ssh, credentials, IP addresses, etc…

You’re also going to need a PUBLIC IP address for this configuration, for this blog we’re using 73.41.232.21 on FastEthernet0/0

First up we need to configure Phase 1 of the IPSEC Tunnel by defining the ISKMP policies and peer pre-shared key.

!crypto isakmp policy 10 encr aes 256 authentication pre-share group 5!crypto isakmp key mysafety address 108.61.152.251!

Now lets define the first sequence in the crypto map which will be used to build the security association;

!crypto map PIA_VPN 10 ipsec-isakmp set peer 108.61.152.251 set transform-set ESP-AES256-SHA1 match address PIA_EAST_US!

You’re going to need to build out the transform set referenced in the crypto map “ESP-AES256-SHA1″;

!crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport!

Now you need to configure the ACL referenced in the crypto map “PIA_EAST_US”. In this case the source and destination UDP port is going to be 1701. You’ll also need to use the public IP address which should be static as the source IP Address int he ACL. In this case 73.41.232.21 is the IP address assigned to the outside interface FastEthernet0/0 whereas 108.61.152.251 is the VPN Gateway IP Address.

!ip access-list extended PIA_EAST_US permit udp host 73.41.232.21 eq 1701 host 108.61.152.251 eq 1701!

Once the IPSEC Configuration has been completed you’ll need to assign the crypto map to the public facing IP Address, in this case FastEthernet0/0;

!interface FastEthernet0/0 crypto map PIA_VPN!

Before we can configure the L2TP virtual tunnel interface we first need to define the pseudowire class configuration. The encapsulation will be set to l2tpv2 and the local interface should be defined as the public facing interface;

!pseudowire-class PIA_L2TP encapsulation l2tpv2 ip local interface FastEthernet0/0!

Now we can define the virtual tunnel interface, in this case its going to be a Virtual-PPP Interface;

interface Virtual-PPP1 description Tunnel to PIA EAST US ip address negotiated ip nat outside ip virtual-reassembly ppp eap refuse ppp chap hostname x4108222 ppp chap password 0 8Mz1wHgZDJ ppp ipcp address accept no cdp enable pseudowire 108.61.152.251 1 pw-class PIA_L2TP

And thats it for the L2TP IPSEC Tunnel configuration. You should now be able to verify that Phase I and Phase II have established successfully as shown below;

PIA-GATEWAY#show crypto isakmp saIPv4 Crypto ISAKMP SAdst src state conn-id status108.61.152.251 73.41.232.21 QM_IDLE 1001 ACTIVEIPv6 Crypto ISAKMP SAPIA-GATEWAY#PIA-GATEWAY#show crypto ipsec sainterface: FastEthernet0/0 Crypto map tag: PIA_VPN, local addr 73.41.232.21 protected vrf: (none) local ident (addr/mask/prot/port): (73.41.232.21/255.255.255.255/17/1701) remote ident (addr/mask/prot/port): (108.61.152.251/255.255.255.255/17/1701) current_peer 108.61.152.251 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 305, #pkts encrypt: 305, #pkts digest: 305 #pkts decaps: 294, #pkts decrypt: 294, #pkts verify: 294 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 73.41.232.21, remote crypto endpt.: 108.61.152.251 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0 current outbound spi: 0xC4E6F422(3303470114) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x97AF5057(2544848983) transform: esp-256-aes esp-sha-hmac , in use settings ={Transport, } conn id: 2001, flow_id: NETGX:1, sibling_flags 80000006, crypto map: PIA_VPN sa timing: remaining key lifetime (k/sec): (4580055/1730) IV size: 16 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xC4E6F422(3303470114) transform: esp-256-aes esp-sha-hmac , in use settings ={Transport, } conn id: 2002, flow_id: NETGX:2, sibling_flags 80000006, crypto map: PIA_VPN sa timing: remaining key lifetime (k/sec): (4580054/1730) IV size: 16 bytes replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas:PIA-GATEWAY#

If you are having problems with Phase I or Phase II you can use the debug crypto isakmp and debug crypto ipsec command(s) to help you better understand why. Google any errors you may receive

If your configuration is correct thus far the Virtual-PPP1 interface should be up/up with an IP Address as shown below;

PIA-GATEWAY#show interface virtual-ppp1Virtual-PPP1 is up, line protocol is up Hardware is Virtual PPP interface Description: Tunnel to PIA EAST US Internet address is 10.10.1.3/32 MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, LCP Open Open: IPCP, loopback not set Keepalive set (10 sec) DTR is pulsed for 1 seconds on reset Last input 00:05:43, output never, output hang never Last clearing of "show interface" counters 00:50:30 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 417 packets input, 5892 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 339 packets output, 6217 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitionsPIA-GATEWAY#

If your Virtual-PPP1 interface is failing to obtain an IP Address and shows UP/DOWN than you can use the debug ppp authentication command to ensure that your credentials are correct.

Routing and NAT Configuration

Before the clients on the inside can access the internet via the L2TP IPSEC VPN you need to setup two static routes and NAT.

The first static route you’ll need is a route to the VPN Gateway via your ISP default gateway. In this case 108.61.152.251 needs to be routed to 73.41.232.1

!ip route 108.61.152.251 255.255.255.255 73.41.232.1!

Next is going to be the default route for all traffic to reach the internet, send it through the tunnel;

!ip route 0.0.0.0 0.0.0.0 Virtual-PPP1!

Next up you need to define the inside and outside NAT zones;

!interface FastEthernet0/1 ip nat inside!interface Virtual-PPP1 ip nat outside!

Once NAT zones have been defined you’ll need to define an ACL which will be used by NAT overload to translate multiple inside machines to the IP address of the virtual-ppp interface. In this case our inside network is 192.168.0.0/24

!ip access-list standard NAT permit 192.168.0.0 0.0.255.255!

Finally we need to define the source NAT statement so that inside hosts referenced by the named acl “NAT” will be overloaded to the Virtual-PPP1 interface.

!ip nat inside source list NAT interface Virtual-PPP1 overload!

Now you’re golden. To test your NAT configuration you can do a traceroute sourced from your inside interface, in this case FastEthernet0/1 to 4.2.2.2 as demonstrated below;

PIA-GATEWAY#traceroute 4.2.2.2 source FastEthernet0/1 probe 1 numericType escape sequence to abort.Tracing the route to 4.2.2.2 1 10.10.1.1 48 msec 2 * 3 184.75.211.129 64 msec 4 38.88.240.133 88 msec 5 69.31.143.24 60 msec 6 154.54.3.93 76 msec 7 4.69.155.208 128 msec 8 4.2.2.2 112 msecPIA-GATEWAY#

As you can see from the traceroute provided above the next hop IP address is going to be 10.10.1.1 which is the IP address of the VPN gateway.

To allow machines on your network to access the internet via this newly build L2TP IPSEC VPN Gateway you just need to change the default gateway on your machines to the inside interface of the newly configured vpn gateway router.

After which you can test your public facing IP address using IP Chicken!

Download the final Configuration!

Click the button below to download the final configuration!

VPN-GATEWAY Final Configuration

If you have any questions or comments please post a comment below! Enjoy….

اكمل القراءة

• twitter
• share
• plus