Thursday, February 7, 2019

CloudShark Holiday PCAP Challenge: Grinchident 2018

This was a challenge I participated in around Christmas time. Below is a copy and paste of the write-up I supplied Cloudshark.

Today, myself and other participants along with the folks from Cloudshark did a webinar to discuss what there is to gain from doing challenges like this and how to build them.

If you would like to try the challenge use this link: https://enterprise.cloudshark.org/blog/holiday-capture-challenge-2018/

BELOW CONTAINS SPOILERS, ALOT OF THEM!!!!

After completing the Cloudshark Halloween challenge, which was a lot of fun (I blogged about it here: https://sealingtech.org/2018/11/14/trick-or-treat-halloween-pcap-challenge-from-cloudshark/ ), sparked my thirst for PCAP challenges, I started the Holiday PCAP challenge: https://enterprise.cloudshark.org/blog/holiday-capture-challenge-2018/ . I really loved how this one had a PCAP inside of a PCAP inside of a PCAP style. I worked through this one pretty quick but I did reach a hard stop. I’m stuck and can’t go any further. Below are my findings.


The challenge starts with 2 PCAP’s: (more will be found—We have 5 so far)
  • grinch_activity.pcapng
  • holiday_chunk_0.pcapng
Before I start any PCAP challenge or begin to look at any PCAP I always perform these few steps:
  • StatisticsàProtocol Hierarchy
  • StatisticsàConversations



This will give us a breakdown of the protocols and conversations we’re seeing before we even dive in to any of the packets. This allows us to treat the PCAP like an onion and slowly peeling off one layer at a time.

Going back to the packet list… as, soon as you open the “grinch_activity.pcapng” file you’re immediately presented with some UDP traffic and an obvious email.

The UDP traffic looks eerily similar to the RTP Stream that was embedded in the Halloween PCAP Challenge. Because the UDP Data made up about 18% of the overall traffic with in the PCAP I thought it would be a good idea to peel off that traffic and get it out of the way.


3 Songs


Using the same procedure for all, I was able to extract 3 songs:
I identified these conversations from the Conversations Statistics window from above.

Step 1:

Right click the first packet in the Packet List and navigate to “Decode As…”. Under the “Current” table heading double click to activate the drop down menu and choose “RTP”.

This instructs Wireshark to use its RTP protocol analyzer against this traffic.


Step 2:

Navigate to: TelephonyàRTPàRTP Streams


Step 3:

In the RTP Streams window click “Analyze”.


Step 4:

In the RTP Stream Anaylsis window click “Play Streams”.


Step 5:

Enjoy!

Export Objects

One of the next things I do almost every time is export all the objects Wireshark can identify.

Navigate to: FileàExport Objectsà HTTP

This will dump only a few files, but very important files.


I quickly grabbed the *.torrent file and threw it in a torrent program. This yielded another PCAP file: “btc.pcapng”.

Now, we have a total of 3 PCAP’s to work with.

I lightly investigated the “mad-holiday-antler.jpg” image but it hasn’t yet yielded me a flag.

Merge PCAPs

Since we now have 3 PCAPs to work with I took the strategy of removing the 3 song streams from the PCAP and merging all 3 into 1 PCAP file.

Export Objects: Part 2

Cloudshark also gave us the Pre-Master-Secret key file to be used with these PCAPs. I applied that file to the PCAP and did the export object procedure again, this time yielding many more objects.


There are some interesting finds to come out of this export:
  • Visits to Cloudshark’s website to specific blog posts(the may give clues to solving some of the challenges 😉)
    • Bittorrent 
    • Memcached 
    • VPN leaks 
  • IMDB for The Grinch Who Stole Christmas 
  • A few visits to Anti-Christmas websites 
  • Bing 
  • CyberChef on Github

Some of these items are clues to solving the Mystery…

Emails

 

Before doing any other deeper investigation lets finish looking at all of the clear text protocol: SMTP

You can navigate to: FileàExport ObjectsàIMF

This will export the *.eml files cleanly and then open them with notepad or notepad++.

Or because the protocols are plain text you can read them in line in the Packet Details in Wireshark.

DNS

Looking back at our protocol statistic we have many obvious DNS requests to lets take a look.

I often like to give special attention to DNS because it’s clear text and you can tell a lot about a network by observing DNS. Also, for the sake of PCAP challenges you can hide a lot in DNS if you wanted.

Out of all the packets there were only a few DNS requests and responses. They didn’t yield any flags but I feel it’s important to document the findings.

IRC (or GRC: Grinch Relay Chat)

Identified in the Protocol Hierarchy(our first step), we can see a small amount of IRC traffic.

IRC traffic typically uses TCP over port 6667 by default. We can identify this traffic using the filter: “irc

In the packet details pane I expand the protocol and right click on “Trailer” and choose “Apply as column”. This allows me to quickly see the text conversation.


It’s a small Christmas poem with the cadence of Dr. Suess How the Grinch Stole Christmas or ‘Twas the Night Before Christmas.

In this poem are a few clues:
  • “in an old protocol where short messages are cached.”
  • “peer-obsessed”, “seeds”, “abhorrent”(rhymes with torrent)
  • “VPN is configured”
  • “sound!”

Memcached (my favorite part)


(Feb 7, 2019 UPDATE: Sake from the Webinar showed a much cleaner and wuicker way to solve this all within Wireshark)

This is chaining together many items and was my favorite to find so far.

To quickly identify the Memcache protocol use the filter: “memcache

This will yield 2 packets. There are many many packets that make up this entire converstation but all your attention can be brought to one packet.

A single session that once reassembled equals 336848 bytes.

I expanded these details and right-clicked the “Value” and chose “Copy as Printable Text”.

I pasted it into a notepad and couldn’t figure out what to do with it.

I saw it had a trailing “==” sign which often indicated Base64 but I couldn’t figure out what I was supposed to do with it.

Keeping this in the back of my head as I browsed around trying to identify different parts of this story I remember seeing CyberChef, and also it seemed like this PCAP was leaving clues within itself. So, I followed the link to CyberChef (https://gchq.github.io/CyberChef).

NOTE: I recently used CyberChef in another CTF and was familiar with it’s capabilities.

I browsed to CyberChef and pasted in what I thought was Base64 and started to build a recipe. I added the “From Base64” ingredient and viola! I had something.



Right there in the first few lines of the Output I saw “mergecap” and also a string of repeating “HAPPYHOLIDAYS”. I knew mergecap was used to merge multiple PCAPs or also split them. So, I figured this must be another PCAP. I clicked the save icon and saved the file as a PCAP and opened it… it worked!!! I had my fourth PCAP!!!.

I merged this PCAP into my larger PCAP I was already working because it looked like it had part of an existing conversation.

UDP

Upon merging the newly found PCAP, from above, I now had 2 strange UDP packets at the top of my Packet List.


Changing the packet view to ASCII yielded the “HAPPYHOLIDAYS” phrase I saw earlier… but something wasn’t quite right. 


I copied the 2 phrases out of Wireshark and into Notepad for a closer look.



Looking through this we can extract something but what is it? If you subtract all the UpperCase letters and leave only the lowercase something emerges. (I feel like I’m using the decoder ring from ‘A Christmas Story’)
I don’t have the full URI so this makes me think this is incomplete. I’m hoping this points me to another PCAP to grab but at this time it is un-confirmed.

Ascii Art

I also found some ascii art which is similar to what was hidden in the Halloween PCAP Challenge, but with a Grinch/Christmas theme.


User Agent Strings

  • GrinchBrowse/1.0 
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:64.0) Gecko/20100101 Firefox/64.0 
  • curl/7.55.0

IP Address in HTTP Header?

I found an IP address in an HTTP header that I’m wondering is this something I should hunt or not. I did some preliminary investigation, and have it pinned to Comcast ISP in the North East. I’m betting this is something that didn’t get scrubbed when using trace wrangler to sanitize the PCAP. I assume this is a real IP address used by Cloudshark offices or one of their employees.



OpenVPN

This I have yet to solve.

NordVPN, seems fitting as "Nord" is French for North, as in the NorthPole, maybe it’s a stretch.

NordVPN CA20

us349.nordvpn.com

I changed the HMAC bytes length to 64 and the packets started lining up properly. You can use the filter “openvpn”, you’ll notice all the “[Malformed Packet]” message removed and expand the header find the “Packet-ID” value and scroll down through the packets you should see them all increment: 1, 1, 2, 2, 3, 3, 4, 4…..


FROM THIS...

...TO THIS

ROT13

Hints were being dropped throughout the PCAP. I found someone browsing to the wiki article for ROT13, which is a type of encoding.

I haven’t yet found a string that I can use this on so I’m still looking.

CyberChef supports ROT13 so I’m poised and ready.

The 5th PCAP: 

https://fs-hpcc.qaggle.net

A co-worker (Scott) pointed me to this site which I had previously seen and dismissed. He shared the screenshot which made me perk up:



I immediately did a view source and discovered a hidden message:
I completely ignored the username/password credential entry because of the source looks like no-matter what you enter it will always return: “Password incorrect. Please try again.”

Now, I have the 5th PCAP:

It, like the other PCAPs, has a UDP packet as the first packet, then my quick glance shows only one other conversation.

The single UDP packet had the same messaging as the other I’ve found adding to my collection: (The middle section)


I’m hoping that this leads me to another PCAP but I can’t seem to get there. I’m missing something.




Sunday, August 19, 2018

EVE-NG in the Cloud

I've been running EVE-NG (http://www.eve-ng.net/) locally as a VM on an old PC I use as an ESXi server for about 6 months. It works great and I've really been loving it lately.

In preparing for CCIE Lab exam I've needed to build and run very large topologies. The amount of resources you need will very greatly based on the virtual images you require. I have found the Cisco IOL images to use the fewest resources and run the most reliably. If your working towards Data Center, Service Provider or other exam tracks you'll likely need more than Cisco IOL and will need to run IOS-XRv, Nexus images, CSR1000v's or others which will consume many more resources.

The topologies I'm working from are the Foundation Labs, Troubleshooting and Full-Scale labs from INE's CCIE v5 Routing and Switching workbook. These labs vary from 14 virtual devices to 24 virtual devices. Specifically the version I'm working with uses the IOSv images which consumes many resources during boot and while running compared to Cisco IOL images.

The resources I have at home in my old PC I'm using as an ESXi server is limited and I needed more resources available to run the larger topologies. This brought me to seeking a way to run EVE-NG on scalable and expandable resources.

All initial credit goes to Arwin Reprakash from https://ithitman.blogspot.com/2018/04/configuring-eve-ng-on-google-compute.html, documenting the process and sharing.




If you have a Gmail account you can activate Google Cloud for your account and get $300 FREE, from Google to spend on their resources.

You might be asking yourself: "How much will $300 get me?"

The cost varies based on the resources you consume.

If you're running IOL images you can get away with one of the lower tiers and leave your VM on for 24 hours/day for nearly a YEAR without paying a dime!!!

If you need to consume more resources obviously it will decrease your free $300 at a faster rate. 8vCPU's and 30GB memory you can run for 24 hours/day for about 40 days straight.

Juts for comparison I took a quick glance at what other vendors offer, here's a cost breakdown:

FULL DISCLOSURE: I have not vetted or tested all of these solutions, I'm listing them based on price comparison only. They each offer different solutions. Choose which ever is best for you!

Google Cloud: FREE $300 

(https://cloud.google.com)

  • 1vCPU 3.75GB Memory = ~$26/Month (About 11 Months of continuous running)
  • 4vCPU 4 GB Memory = ~$78/Month (About 3.8 Months of continuous running)
  • 8vCPU 30 GB Memory = ~$195/Month (About 1.5 Months of continuous running)



Packet.net (Bare-Metal) NOT FREE

t1.small.x86: ($0.07/hr) [730 hours = $51.10] (https://www.packet.net/bare-metal/servers/t1-small/)

  • 8 GB of DDR3 RAM
  • 80 GB of SSD
  • 4 Physical Cores @ 2.4 GHz (1 × Atom C2550)

c1.small.x86 ($0.40/hr) [730 hours = $292.00] (https://www.packet.net/bare-metal/servers/c1-small/)

  • 32 GB of DDR3 ECC RAM
  • 120 GB of SSD (2 × 120 GB in RAID 1)
  • 4 Physical Cores @ 3.5 GHz (1 × E3-1240 v5)

m2.xlarge.x86 ($2.00/hr) [730 hours = $1460.00] (https://www.packet.net/bare-metal/servers/m2-xlarge/)

  • 384 GB of DDR4 ECC RAM
  • 120 GB of Redundant SSD (2 × 120 GB in RAID 1)
  • 3.8 TB of NVMe Flash
  • 28 Physical Cores @ 2.2 GHz (2 x Xeon Gold 5120)


Cloud My Lab: Free Trial

https://cloudmylab.com/cciers/#price
https://cloudmylab.com/eve-ng/#cycle-monthly


Configs:


Create the nested virtualization supported image based on Ubuntu 16.04 LTS

gcloud compute images create nested-virt-ubuntu --source-image-project=ubuntu-os-cloud --source-image-family=ubuntu-1604-lts --licenses="https://www.google.com/compute/v1/projects/vm-options/global/licenses/enable-vmx"



Edit sshd_config to allow "root" user to login

nano /etc/ssh/sshd_config

!-change:
PermitRootLogin yes

PasswordAuthentication yes



Change interface name to "eth0"

nano /etc/udev/rules.d/70-persistent-net.rules



Reboot

shutdown -r now



Download the gpg.key, install the new repository, install eve-ng

wget http://www.eve-ng.net/repo/eczema@ecze.com.gpg.key

apt-key add eczema@ecze.com.gpg.key

apt update

add-apt-repository "deb [arch=amd64] http://www.eve-ng.net/repo xenial main"

apt update

apt-get install eve-ng

apt-get install eve-ng



Remove the 4.15 Kernel, use only 4.9 eve-ng Kernel

cd /boot/

mkdir ./old/

mv *4.15* ./old/



Edit grub

sed -i -e  's/GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 noquiet"/' /etc/default/grub

update-grub



Create a new non-root user:

sudo adduser showipintbri

sudo usermod -a -G sudo shoipintbri



Disable root from sshing

nano /etc/ssh/sshd_config

!-change:
PermitRootLogin no

Thursday, August 2, 2018

Everything You Need to Know About OSPF

"Everything you'll ever need to know about OSPF" is a bold statement but is goes back to "Mastering the Foundations" something I've been saying for the past 25 days. If you can master these OSPF foundations the rest is icing on the cake.

PRO-TIP: Don't treat this as a long list of items to memorize but rather a checklist of topics to lab up.

Default Behavior

  • Won't start unless OSPF can determine a router-id
  • Router-id determined:
    1. Configured router-id
    2. Highest loopback IP address
    3. Highest interface IP address
  • Every router within an area must have the same OSPF database
  • Filtering/Summaries happen at the ABR
  • Default Priority = 1, highest priority becomes the DR (where applicable)
    • A Priority of "0" means router will NOT participate in DR/BDR elections.

OSPF Network Types

Broadcast

  • Default for Ethernet interfaces
  • Elects DR/BDR
  • Uses Multicast
  • Allows more than 2 routers on a link
  • Timers: Hello - 10, Dead  - 40

Non-Broadcast

  • Elects a DR/BDR
  • Uses Unicast (neighbor statements)
  • Allows more the 2 routers on a link
  • Timers: Hello - 30, Dead - 120

Point-to-Point

  • Default for Serial and Tunnel interfaces
  • Does NOT elect DR/BDR
  • Uses Multicast
  • Only 2 routers allowed on a link
  • Timers: Hello - 10, Dead - 40

Point-to-MultiPoint

  • Does NOT elect DR/BDR
  • Uses Multicast
  • Allows more than 2 routers on a link
  • Installs /32 host routes per neighbor
  • Timers: Hello - 30, Dead - 120

Point-to-MultiPoint Non-Broadcast

  • Does NOT elect DR/BDR
  • Uses Unicast (neighbor statements)
  • Allows more than 2 routers on a link
  • Installs /32 host routes per neighbor
  • Timers: Hello - 30, Dead - 120

Loopback

  • Default for Loopback interfaces
  • When included in OSPF, uses a /32
    • To advertise with mask other-than /32, manually set network type to "point-to-point"


LSA Types

LSA Type-1: Router LSA's

  • Originated from each router
  • Flooded within an area
  • Tells the area about all the links participating in OSPF and are associated with that area

LSA Type-2: Network LSA's

  • Originated by the DR
  • Only DR can originate Type-2 LSA's (If there is no DR their aren't any Type-2's)
  • This LSA tells all the routers in an area about all the routers on a shared medium like Ethernet

LSA Type-3: Summary LSA's

  • Originated by an ABR
  • Carry the destination network prefixes from one area into another
From nonbackbone > backbone
  • Connected Routes
  • Intra-Area Routes
From backbone > nonbackbone
  • Connected Routes
  • Intra-Area Routes
  • Inter-Area Routes

LSA Type-4: ASBR-Summary LSA's

  • Originated by an ABR
  • Tells all the other areas about the ASBR
  • Tells all the other areas "to get to this Router-ID(ASBR) go through Me(ABR)!"

LSA Type-5: External LSA's

  • Originated by an ASBR
  • Flooded through out the OSPF domain, except into stubby areas
  • Contains the Network prefix and subnet-mask for the external network

LSA Type-7: NSSA External LSA's

  • Originated by ASBR
  • Exist only in a Not-So-Stubby Area (NSSA)
  • Are NOT flooded outside the area they were originated

Area Types

Backbone Area

  • Area 0
  • Act's as the HUB for all other areas
  • Accepts all LSA Types

Normal Area

  • All non-stub areas
  • Allows LSA's Type: 1, 2, 3, 4, 5 & External Default

Stub Area

  • Allows LSA Types: 1, 2, 3 & Summary Default Route ( No External Type-5's )

Totally Stubby Area

  • Allows LSA Types: 1, 2 & Summary Default Route

Not-So-Stubby Area (NSSA)

  • Allows LSA Types: 1, 2, 3, 7 ( No External Type-5's )
  • NSSA's allow redistributing into an area but still maintain it's 'stub area' properties (not allowing External Type-5's)
  • Redistributed routes are converted to Type-7 LSA's and advertised throughout the area by the ASBR
  • The ABR converts Type-7 LSA's into Type-5's before advertising them into the backbone area.
  • LSA Type-7's are only flooded within the area they originate

Totally Not-So-Stubby Area (NSSA)

  • Allows LSA Types: 1, 2, 7 & Summary Default Route ( No External Type-5's )
  • NO LSA Type-3's


Route Types

  • O = Intra-area Route
  • O IA = Inter-area Route (Generated by Type-3 LSA's)
  • E1 = External Metric Type-1 (Generated by Type-5 LSA's)
  • E2 = External Metric Type-2 (Generated by Type-5 LSA's)
  • N1 = NSSA Metric Type-1
  • N2 = NSSA Metric Type-2


Saturday, July 7, 2018

#100DaysOfLabbing - Day 5

Day 5 I fought environment issues for more time than I was labbing. It was frustrating and looking back not the best way to spend my time.

A lab that worked on Wednesday, didn't work on Thursday, or on Friday but worked on another platform.

I started working on DMVPN with OSPF as the Routing protocol, and that too didn't work in one platform but did work on another.

The Video:

Day 5

Friday, July 6, 2018

#100DaysOfLabbing - Day 4

Day 4 was rough. My plan was to breeze through the same lab I did yesterday so I could really solidify it, but the universe had other plans.

I hit the ground running with IPv4 DMVPN but fell on my face for IPv6. I spent 30 minutes configuring verifying and working the different phases of IPv4 DMVPN and spent 2.5 hours trouble shooting IPv6. :face_palm: I cannot waste time like that. This was a learning experience but I'll never get that time back.

Also this blogsite was broken and I had to fix it.

I found this resource today:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/eigrp-route-map.html

The Video:

Day 4


Wednesday, July 4, 2018

#100DaysOfLabbing - Day 3

Dual Stack - Multi Hub - DMVPN

tl;dr - After failure, success tastes so much sweeter.

Today was all over the map. This morning I came into the labs charging like a bull. I wanted to do IPv6 DMVPN and I did! I was successful. That carried me on a little engineering high knowing I had done something I have never tried before that seemed so foreign and came out of the battle victorious.

But, I'm wise enough to know anyone can get lucky once, but very few get lucky twice.

So I wiped the routers and did it again, minimal errors and mostly from memory... success.

While I was completing my second run through the configs and topology I got an idea for a topology and a challenge: Dual Stack - Multi Hub - DMVPN

I felt comfortable enough with my understanding of the component technologies that I felt could pull it off and I shrugged "what the hell... we'll do it live". (https://www.youtube.com/watch?v=eUFY8Zw0Bag)

As I began the recording I can be quoted as saying something to the effect of "this might take about 30 minutes"... 65 minutes later I ended up at a dead end and I failed.

I got burned by a couple of items:

  • I had to pull off the tunnel protection on the IPv4 DMVPN and put it back on for it too work. I'm not sure if this is a bug or have I unknowingly fell victim of order of operations and I didn't know it?
  • Others were oversights and mis-configurations.

Have a Process:

When ever I'm writing configs they rarely look like the running-configs from a routers output or are in the same order, instead I build them in layers, like a cake.
  1. Think ahead about all the elements that you'll need to complete a task.
  2. Which configurable elements can be grouped and entered at the same time?
  3. In-between layers, what can you verify?
Following the process from above I would order the tasks as follows:

    1. Underlay (NBMA) addresses, connectivty
    2. Loopbacks
    3. Crypto
    4. Tunnel Interface for IPv4 topology
    5. Routing protocol for IPv4 topology
    6. Verify
    7. Tunnel interface for IPv6 topology
    8. Routing Protocol for IPv6 topology
    9. Verify

The Resources:

I found this group of documents extremely helpful from all aspects of this configuration. It includes specifics on IPv6 addressing which I still wasn't to keen on, but know I'm much more comfortable. It also broke down the elements we need for the IPv6 DMVPN.


The Videos:

Day 3 - Part 1 (more than 1 hour)

Day 3 - Part 2

The Configs:

R1: (IPv4 Hub, IPv6 Spoke)

hostname R1

no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef

crypto isakmp policy 1
 authentication pre-share
crypto isakmp key SHOWIPINTBRI address 0.0.0.0
crypto isakmp key SHOWIPINTBRI address ipv6 ::/0
!
!
crypto ipsec transform-set MYTRANS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile DMVPN
 set transform-set MYTRANS

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback6
 no ip address
 ipv6 address FC01::1/128
 ipv6 eigrp 6
!
interface Tunnel0
 ip address 10.123.234.1 255.255.255.0
 no ip redirects
 no ip split-horizon eigrp 90
 ip nhrp map multicast dynamic
 ip nhrp network-id 1234
 tunnel source 172.17.100.1
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
!
interface Tunnel1
 no ip address
 ipv6 address FE80::1 link-local
 ipv6 address FC00:1234::1/64
 ipv6 eigrp 6
 ipv6 nhrp map FC00:1234::4/64 2001::4
 ipv6 nhrp map multicast 2001::4
 ipv6 nhrp network-id 10123
 ipv6 nhrp nhs FC00:1234::4
 ipv6 nhrp shortcut
 tunnel source 2001::1
 tunnel mode gre multipoint ipv6
 tunnel protection ipsec profile DMVPN
!
interface GigabitEthernet0/0
 ip address 172.17.100.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
 ipv6 address 2001::1/48

router eigrp 90
 network 0.0.0.0
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Loopback0

router eigrp ipv6
 !
 address-family ipv6 unicast autonomous-system 6
  !
  af-interface GigabitEthernet0/0
   shutdown
  exit-af-interface
  !
  topology base
  exit-af-topology
 exit-address-family

line con 0
 logging synchronous


R2: (IPv4 Spoke, IPv6 Spoke)

hostname R2

no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef

crypto isakmp policy 1
 authentication pre-share
crypto isakmp key SHOWIPINTBRI address 0.0.0.0
crypto isakmp key SHOWIPINTBRI address ipv6 ::/0
!
!
crypto ipsec transform-set MYTRANS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile DMVPN
 set transform-set MYTRANS

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Loopback6
 no ip address
 ipv6 address FC02::2/128
 ipv6 eigrp 6
!
interface Tunnel0
 ip address 10.123.234.2 255.255.255.0
 no ip redirects
 ip nhrp map multicast 172.17.100.1
 ip nhrp map 10.123.234.1 172.17.100.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.123.234.1
 tunnel source 172.17.100.2
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
!
interface Tunnel1
 no ip address
 ipv6 address FE80::2 link-local
 ipv6 address FC00:1234::2/64
 ipv6 eigrp 6
 ipv6 nhrp map FC00:1234::4/64 2001::4
 ipv6 nhrp map multicast 2001::4
 ipv6 nhrp network-id 10123
 ipv6 nhrp nhs FC00:1234::4
 ipv6 nhrp shortcut
 tunnel source 2001::2
 tunnel mode gre multipoint ipv6
 tunnel protection ipsec profile DMVPN
!
interface GigabitEthernet0/0
 ip address 172.17.100.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
 ipv6 address 2001::2/48

router eigrp 90
 network 0.0.0.0
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Loopback0

router eigrp ipv6
 !
 address-family ipv6 unicast autonomous-system 6
  !
  af-interface GigabitEthernet0/0
   shutdown
  exit-af-interface
  !
  topology base
  exit-af-topology
 exit-address-family

line con 0
 logging synchronous


R3: (IPv4 Spoke, IPv6 Spoke)


hostname R3

no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef

crypto isakmp policy 1
 authentication pre-share
crypto isakmp key SHOWIPINTBRI address 0.0.0.0
crypto isakmp key SHOWIPINTBRI address ipv6 ::/0
!
!
crypto ipsec transform-set MYTRANS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile DMVPN
 set transform-set MYTRANS

interface Loopback0
 ip address 3.3.3.3 255.255.255.255

interface Loopback6
 no ip address
 ipv6 address FC03::3/128
 ipv6 eigrp 6

interface Tunnel0
 ip address 10.123.234.3 255.255.255.0
 no ip redirects
 ip nhrp map multicast 172.17.100.1
 ip nhrp map 10.123.234.1 172.17.100.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.123.234.1
 tunnel source 172.17.100.3
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN

interface Tunnel1
 no ip address
 ipv6 address FE80::3 link-local
 ipv6 address FC00:1234::3/64
 ipv6 eigrp 6
 ipv6 nhrp map FC00:1234::4/64 2001::4
 ipv6 nhrp map multicast 2001::4
 ipv6 nhrp network-id 10123
 ipv6 nhrp nhs FC00:1234::4
 ipv6 nhrp shortcut
 tunnel source 2001::3
 tunnel mode gre multipoint ipv6
 tunnel protection ipsec profile DMVPN

interface GigabitEthernet0/0
 ip address 172.17.100.3 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
 ipv6 address 2001::3/48

router eigrp 90
 network 0.0.0.0
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Loopback0

router eigrp ipv6
 !
 address-family ipv6 unicast autonomous-system 6
  !
  af-interface GigabitEthernet0/0
   shutdown
  exit-af-interface
  !
  topology base
  exit-af-topology
 exit-address-family

line con 0
 logging synchronous


R4: (IPv4 Spoke, IPv6 Hub)

hostname R4

no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef

crypto isakmp policy 1
 authentication pre-share
crypto isakmp key SHOWIPINTBRI address 0.0.0.0
crypto isakmp key SHOWIPINTBRI address ipv6 ::/0
!
!
crypto ipsec transform-set MYTRANS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile DMVPN
 set transform-set MYTRANS

interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Loopback6
 no ip address
 ipv6 address FC04::4/128
 ipv6 eigrp 6
!
interface Tunnel0
 ip address 10.123.234.4 255.255.255.0
 no ip redirects
 ip nhrp map multicast 172.17.100.1
 ip nhrp map 10.123.234.1 172.17.100.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.123.234.1
 tunnel source 172.17.100.4
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
!
interface Tunnel1
 no ip address
 ipv6 address FE80::4 link-local
 ipv6 address FC00:1234::4/64
 ipv6 eigrp 6
 no ipv6 split-horizon eigrp 6
 ipv6 nhrp map multicast dynamic
 ipv6 nhrp network-id 10123
 ipv6 nhrp redirect
 tunnel source 2001::4
 tunnel mode gre multipoint ipv6
 tunnel protection ipsec profile DMVPN
!
interface GigabitEthernet0/0
 ip address 172.17.100.4 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
 ipv6 address 2001::4/48

router eigrp 90
 network 0.0.0.0
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Loopback0
!
!
router eigrp ipv6
 !
 address-family ipv6 unicast autonomous-system 6
  !
  af-interface GigabitEthernet0/0
   shutdown
  exit-af-interface
  !
  af-interface Tunnel1
   no split-horizon
  exit-af-interface
  !
  topology base
  exit-af-topology
 exit-address-family

line con 0
 logging synchronous