I fought FreeRADIUS and FreeRADIUS won

Back to work

So... last I had written, several months ago, I had managed to add my CentOS server to my domain and was going to work on getting FreeRADIUS running there, so I could have my Cisco virtual devices authenticate against it.

Turns out, this was WAY more complicated then I thought it would be.

I'll spare the gory details, but long story short, I don't like the way FreeRADIUS tries to do... a lot of things.

Luckily, I complained about this on IRC, and someone else asked why I wasn't just using TACACS+. The reason I hadn't is because I don't have access to Cisco's TACACS+ server software - and I assumed there wasn't a free implementation of it out there.

As it turns out, when you assume, you may waste several months on a wild and unnecessary goose chase.

TACACS.net

There is indeed a free TACACS+ implementation, available from tacacs.net.

It's also ridiculously easy to set up. In addition to the normal configuration options (IP to bind to, mainly), all I had to do was specify:

authentication.xml

<UserGroup>

<Name>Router Access</Name>

<AuthenticationType>Windows_Domain</AuthenticationType>   

<LDAPServer>outpost-hub.outpost.amateria:636</LDAPServer>

<LDAPUseSSL>1</LDAPUseSSL>

<LDAPUserDirectorySubtree>OU=Accounts,DC=outpost,DC=amateria</LDAPUserDirectorySubtree> 

<LDAPGroupName>Router Access</LDAPGroupName>

</UserGroup>

clients.xml

<ClientGroup Name="INTERNAL">

<Secret ClearText="hidden" DES=""></Secret>

<Clients>

<Client>172.*</Client>

<Client>10.*</Client>

</Clients>

</ClientGroup>

authorization.xml

<Authorization>

<UserGroups>

<UserGroup>Router Access</UserGroup>

</UserGroups>

<ClientGroups>

<ClientGroup>INTERNAL</ClientGroup>

</ClientGroups>

<Shell>

<Permit>.*</Permit>

</Shell>

</Authorization>

And... that's it. In a nutshell, it takes requests from TACACS+ clients in the 172.* and 10.* ranges, looks up user accounts in the "OU=Accounts" DN, and confirms they belong to the "Router Access" LDAP group, and grants them permission to all commands on the router. (I could've made it more granular, but didn't see a need at this point.)

As a bonus, since it runs on a Windows host inside the domain, it can use the host's Kerberos credentials to access ActiveDirectory!

Bringing it online... jk

At this point, I went to configure one of my virtual Cisco routers to use TACACS for login, and... it didn't work.

After some digging, I found that for some reason, my CentOS and Windows Server machines couldn't route to the GNS3 LAN any more.

At this point, though, I decided that the original mesh design I had come up with, was probably overkill for what I was learning at the time. And also that it would probably need redesigning in the future when I learned new stuff.

So I killed the whole setup and went to a single router for now.

Also, I configured the input VTY lines for SSH.

At this point, I found something unusual - which is that trying to actually login to the router in question would hang for about 30-60 seconds, and then fail.

Coincidentally, at the same time, the CPU usage on the GNS3 VM would shoot up to about 100% and stay there. Nothing I seemed to do (switching from SSH to Telnet authentication) seemed to make a difference...

So for now, I'm just assuming that TACACS+/LDAP authentication would be working in a real environment, and moving on - because I've wasted more time on this than I'd like to admit.

I'm not really what I'll be moving on to next, but, we'll see.

Day 3.4: DHCP and subnetting

Introduction

In the last entry, I set up a few things:

• Routing between all the virtual routers on the network.
• To do this, I enabled RIP on all the core (Core, Edge, and Access) routers for all the networks in the LAN.
• Configured the Core0 router as the default gateway, and configured RIP to propagate default route information across the network.
• Configured the Win2016 VM with a direct connection to the Internet, since while GNS3 routes traffic internally quickly enough, it's too slow for Internet connectivity. Win2016 still has access to the virtual LAN as well.

Onwards!

Next step is going to be setting up user access and VLANs (which, by necessity, involves configuring DHCP.)

But VLANs first.

Jumping over to my Access1 router, I set up my two user VLANs, which I designated 101 and 102:

Access1(vlan)#vlan 101

VLAN 101 added:

    Name: VLAN0101

Access1(vlan)#vlan 102

VLAN 102 added:

    Name: VLAN0102

Immediate problem: VLANs are apparently stored in Flash memory as opposed to NVRAM... and Access1 is not configured with any Flash memory.

Shut down switch. Go into configuration in GNS3. Add an 8MiB PCMCIA disk. Restart switch.

format flash:

Okay... now I can create my VLANs and update the database.

Next up: configure an IP address for each VLAN interface to use.

Access1(config)#interface Vlan101

Access1(config-if)#ip address 10.100.1.1 255.255.255.0

Access1(config-if)#no shut

Access1(config-if)#exit

Access1(config)#interface Vlan102

Access1(config-if)#ip address 10.100.2.1 255.255.255.0

Access1(config-if)#no shut

Access1(config-if)#exit

Access1(config)#

Since my VLANs aren't crossing multiple switches, I don't need to work about trunking to other switches. All I need to do is configure the appropriate Ethernet ports for the appropriate VLANs. GNS3 tells me in the Topology Summary which VMs are connected to which ports:

Access1#config t

Enter configuration commands, one per line.  End with CNTL/Z.

Access1(config)#int fa3/0

Access1(config-if)#switchport access vlan 101

Access1(config-if)#ex

Access1(config)#

*Mar  1 00:20:00.015: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan101, changed state to up

Access1(config)#int fa3/1

Access1(config-if)#switchport access vlan 102

Access1(config-if)#^Z

Access1#

And...

Access1#show vlan-switch

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

101  VLAN0101                         active    Fa3/0

102  VLAN0102                         active    Fa3/1

All right, VLANs are set. One more thing first, configure each VLAN interface to use the Windows 2016 DHCP server.

Access1(config)#int Vlan101

Access1(config-if)#ip helper-address 10.1.0.100

Access1(config-if)#ex

Access1(config)#int Vlan102

Access1(config-if)#ip helper-address 10.1.0.100

Access1(config-if)#^Z

Access1#

Now to jump over to Windows and set up the DHCP server.

There's a few different options that needed to be set up:

I created a Superscope specifically to cover user VLANs, and then added a Scope for each VLAN to assign IP addresses within that subnet.

I also set a couple different server-wide options to control what gets assigned to all DHCP clients:

The two Router addresses are for the two interfaces of Core0, the DNS server is the IP address of the Windows 2016 VM.

Time to boot up my Windows 8 VM and see if it gets an IP address successfully.

Probably should've taken care of this first. Oh well.

After the VM came up, I discovered I was getting an address assigned by VMware. As it turns out, you have to start the VMs within GNS3 in order for GNS3 to control them.

But when I tried to do that, I got this message:

After a little digging, I discovered that GNS3 "takes control" of pre-configured VMware virtual networks while it's running. I had only configured it to use a single VMnet, and that was already in use by Win2016. After giving it control of several more VMnets and assigning Windows8 to one of those VMnets, I tried again:

I'll take "error messages I don't understand" for $400, Alex.

Oddly, the VM itself started up with no problem, although it had no network connectivity. I tried one more option: the "Allow GNS3 to override non custom VMware adapter," which I finally discovered had a tooltip informing me that this would allow GNS3 to control the network adapters belonging to the VM.

Still nothing.

After doing some research, I found a forum post suggesting that Windows-based clouds (which I did indeed have) were not as reliable as clouds running inside the GNS3 VM. Following the post's suggestion, I added a network adapter to the GNS3 VM, bridged to my home LAN, and rebooted the GNS3 VM.

GNS3 itself apparently did not like that I was changing its VM while it was running, and complained when I tried to add a new cloud. I opted to just restart GNS3 and try again.

Success... except I was now getting that error message when trying to start up Windows 2016.

At this point I noticed that when I was trying to configure VMnets in GNS3, it was trying to start two services related to Netgroup Packet Filter, that appeared to start and then stop. I figured that all my network interface shifting might have broken something on my local machine, so I decided to reboot.

I started up Win2016, so far so good - then the rest of my virtual routers - then Windows 8. All well and good, except... no IP address.

Oops. Apparently I forgot to save my Access1 configuration before restarting.

After rebuilding the configuration... no DHCP.

Time to enable UDP debugging on Access1 and try a DHCP renew:

Access1#debug ip udp
UDP packet debugging is on
Access1#
*Mar  1 00:07:10.863: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308
*Mar  1 00:07:10.867: UDP: sent src=10.100.2.1(67), dst=10.1.0.100(67), length=308

UDP packets are making it out, but not coming back. Checking on the next hop, InternalEdge2... no UDP packets are coming through, and yet, I can tracert to the DHCP server just fine.

Turning on IP error debugging on InternalEdge2 reveals:

InternalEdge2#debug ip error

IP packet errors debugging is on

InternalEdge2#

*Mar  1 00:31:01.927: IP: s=10.1.0.100 (FastEthernet2/0), d=10.100.2.1, len 337, dispose ip.noroute

There's the problem. I never added my user subnets to the RIP network listing on Access1, and so the rest of the network has no idea how to reach those subnets. Easy fix, at least:

Access1#config t

Enter configuration commands, one per line.  End with CNTL/Z.

Access1(config)#router rip

Access1(config-router)#network 10.100.0.0

Access1(config-router)#^Z

Access1#

Checking the route listing on InternalEdge2 now shows a route to the 10.100.0.0 networks. DHCP renewed, and...

Got it!

Next step

Not sure, really. I'll figure something out.

Day 3.3: Setting up routing

Introduction

Yesterday I built a network of virtual routers in GNS3 and connected my VMs to them. Today I'm going to work on configuring them to actually route traffic around the virtual network.

Getting started

As a reminder, here's what the network looks like right now:

To start out, I figured I should configure Core0 to connect to the Internet. Essentially, I started with the instructions here to set my "external" interface on Core0 (Fa0/0) for DHCP:

Core0#

*Mar  1 00:13:24.639: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 172.20.179.154, mask 255.255.0.0, hostname Core0

Core0#

So far so good - Fa0/0 now has an IP address on my home LAN. Equally importantly, it now has a default gateway assigned for routing traffic out to the Internet.

Core0#ping 75.75.75.75

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 75.75.75.75, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Okay, my bad. The default route forwards out to Fa0/0, but there's no default gateway set.

Core0(config)#ip route 0.0.0.0 0.0.0.0 172.20.0.1 permanent

Core0(config)#^Z

Core0#

*Mar  1 00:24:31.687: %SYS-5-CONFIG_I: Configured from console by console

Core0#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.20.0.1 to network 0.0.0.0

C    172.20.0.0/16 is directly connected, FastEthernet0/0

     172.25.0.0/24 is subnetted, 2 subnets

C       172.25.1.0 is directly connected, FastEthernet1/0

C       172.25.2.0 is directly connected, FastEthernet2/0

S*   0.0.0.0/0 [1/0] via 172.20.0.1

               is directly connected, FastEthernet0/0

Core0#ping 75.75.75.75

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 75.75.75.75, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/78/96 ms

Core0#

Much better.

Next step is configuring the rest of the routers to learn routes. At this point, for simplicity, I'm going to use RIP.

Fortunately, GNS3 lets me edit each router's startup-config in a text editor so I don't have to manually enter all the config commands on each router to add:

router rip
version 2
network 172.25.0.0
network 172.26.0.0
network 172.27.0.0
network 172.28.0.0
network 172.29.0.0
no auto-summary

Next up, configure Core0 to propagate its static route via RIP:

Core0(config-router)#default-information originate

A quick check of Core2 confirms that the default route has propagated:

Core2#sh ip rip database

0.0.0.0/0    auto-summary

0.0.0.0/0

    [1] via 172.25.2.1, 00:00:01, FastEthernet0/0

Unfortunately, I can't ping 75.75.75.75 from Core2.

Tracerouting shows that packets are making it to Core1 and no further.

Core2#traceroute 75.75.75.75

Type escape sequence to abort.

Tracing the route to 75.75.75.75

  1 172.25.2.1 64 msec 64 msec 60 msec

  2  *

Oops. Apparently GNS3 Clouds don't work the way I had thought - I need to enable NAT so that Core0 can translate packets between my virtual LAN and my home LAN.

After some quick changes (irrelevant lines omitted):

interface FastEthernet0/0

 ip nat outside

interface FastEthernet1/0

 ip nat inside

interface FastEthernet2/0

 ip nat inside

ip nat inside source list 1 interface FastEthernet0/0 overload

!

access-list 1 permit 172.25.0.0 0.0.255.255

access-list 1 permit 172.26.0.0 0.0.255.255

access-list 1 permit 172.27.0.0 0.0.255.255

access-list 1 permit 172.28.0.0 0.0.255.255

access-list 1 permit 172.29.0.0 0.0.255.255

I can now ping the outside world from Core2.

Next up: configure default route propagation between all core routers with default-information originate.

Even after doing this, route information is not making it to Access1.

After some digging, I discovered that neither Core1 or Core2 was sending RIP updates to Access1 because I'd somehow forgotten to activate that interface on both Core1 and Core2.

After fixing this, I tried to ping 75.75.75.75 from Access1 - it worked, but only with a 40-60% success rate. Same with most other Internet sites I tried.

Problematically, this doesn't appear to happen if I try it from my physical machine, and I don't have this problem with pings anywhere in my home LAN. It looks like the latency within GNS3 - while not a problem as long as I'm inside my own network - is too slow for traffic to the Internet.

This isn't really a problem, except that my Windows 2016 server needs to be able to access the Windows Update service, and it can't do that if packets are constantly timing out.

Fortunately, this should be a fairly easy fix - I can add a second network adapter to that VM in VMware, connect it directly to my home LAN (bypassing GNS3) and set that as the default route for all traffic not headed for my virtual LAN.

So at this point, my W2016 VM has two network connections: SIMULCRON (connected to my virtual LAN) and EXTERNAL (connected directly to my home LAN.)

(It was also at this point that I switched ExtEdge2 back to a two-port router, and added a generic switch connecting the Windows 2016 VM to it, for simplicity configuring the router.)

Here's what my routing table ended up looking like:

Oddly, at this point, I can access the Internet and ping ExtEdge2, but I can't reach the rest of the virtual LAN.

(Sidenote: I discovered during this process that GNS3 doesn't handle editing of startup-config via the text editor very well if you do it while the VND is running.)

Not too soon after, I realized I'd never configured ExtEdge2 to advertise its path to Win2016 (which is on the 10.1.0.0/16 network, rather than the rest of the virtual network, which is a 172.* network.) After adding 10.1.0.0 to the RIP database on ExtEdge2, everything worked perfectly - and I confirmed I can ping from Core0 to Win2016, and back!

Next up...

Next step will be setting up user VLANs, like I planned in the original network diagram.

As an aside, while network performance is fine, Win2016 is struggling to paint the screen when I'm doing command-line stuff. I may also start using VPCS simulators to test network connectivity.

Day 3.1 - Customizing GNS3

Introduction

In the last entry, after some VMware headaches, I got GNS3 up and running. Next step: add the customization I need to build my virtual LAN.

VND Templates

If you recall, I said I was going to refer to virtual network devices running in GNS3 as VNDs to avoid confusing them with virtual traditional machines running in VMWare.

When it comes to VNDs, GNS3 operates from "templates," which are a collection of hardware settings and the specification of what IOS ROM image to use for the VND. VNDs are instantiated using this template, and then configured like a standard hardware device.

When I left off, GNS3 had just asked me what kind of template I wanted to create first:

I'm going to start by creating a basic IOS router template, which will work for now.

First question is whether I want to run the VND inside the GNS3 VM, or on my local computer. I went with the GNS3 VM.

Next I was prompted for an IOS image. I selected the image file I had on hand (Very basic Cisco 2691, with Enterprise Base feature set.)

At this point, suddenly, GNS3 found itself unable to talk to the VM again.

I noticed that it was trying to connect to an IP address on my home LAN... which the GNS3 server does not have, since it's operating inside a host-only network.

I went into Preferences and specified for the GNS3 server to bind to my VMware virtual NIC assigned to the host-only network. When I did this, the GNS3 VM rebooted. After it came back up, I noticed the VM was now showing green in GNS3, which it wasn't before. Good sign.

I went back to add the IOS image and this time it worked perfectly.

Next I was prompted to name my template and specify the platform (2691.)

Next, I was prompted for the default RAM. I checked Cisco's website and found the minimum RAM for this image was 128MB so I went with that.

Next was selecting what network adapters should be attached by default to new instantiations of this template. I only planned to use 1 slot, so I used the default.

Next was selecting a default WAN interface card for new instantiations. I don't need one, so I left it alone.

Next I was prompted for an "idle-pc" value, which is apparently necessary to keep IOS from using up 100% of a CPU core. Helpfully, there was a button to find it, which took about 30 seconds.

I now had a ready-to-use Cisco 2691 template, ready to go.

Adding in VMWare VMs

For some reason, GNS3 also refers to VMWare VMs as "templates." I'm not really sure why this is, because there's only ever one instance of a particular VM. Regardless.

Anyways. Essentially, I followed the steps in this document to add my existing Windows 2016 Server VM as a template.

One problem I have with GNS3's documentation is that it's written almost entirely in the form of tutorials, and is pretty light on the explanations of why you're doing what you're doing.

Mainly, when I get to the part telling me what to do on the Network settings tab:

Well, a few things. For one, my screenshot doesn't match theirs - I only have one checkbox, they have two. Second, I don't know what any of those boxes mean (aside from Type) and whether they might be important.

Regardless...

On the "VMware Preferences/Advanced local settings" tab, the document says to have GNS3 manage VMnets 2-8. I'm just going to have it manage VMnet 2, since that's the one I assigned for my lab experiments.

After clicking "Configure" on that screen, GNS3 runs some commands to assert control of VMnet2.

Testing it out

At this point, I don't want to go through the trouble of configuring a Cisco router just yet - I just want to make sure I configured everything correctly.

First things first: create a new project in GNS3, and obtain a blank canvas:

Note that over on the left, I have the "End Devices" section open and you can see my VM (and a few other things that will be useful later) available for placement. If I opened up the "Routers" section, you would see my 2691 router template available for placement.

I'm gonna do a couple things: drag my VM over and drop it on the canvas to add it to my network, and drag a "Cloud" object over to the canvas as well.

When I do the second one, I get this question:

Before I answer this, let me try and explain what I think a Cloud object is. (I'm not 100% sure because of the way GNS3's documentation is written.)

As best I can tell, a Cloud can do a handful of things. The main one - at least, the main one I'm concerned with for now - is the ability to make a network interface on a machine (physical or virtual) act as a "proxy" for an interface attached to a VND/VM.

It'll probably make more sense if I demonstrate. But long story short, I choose Amateria (my local physical machine) because I want traffic to flow through my home LAN, which my GNS3 VM is not directly connected to.

After that, I have to configure the Cloud before I can use it.

Essentially, at this point, I've configured Cloud 1 so that it can "proxy" traffic out through my physical machine's Local Area Connection, onto my home LAN.

Next step is to create a link between my Windows VM and Cloud-1, using the "Add a link" button on the left. When I click the Windows VM, I'm prompted to select an interface on the VM, and the same when I click the Cloud. (Each only has one option right now, but I could add more.)

Once it's done, it looks like this.

On the right, you can see a list of connected GNS servers, and what's running on them. At this point, I don't have anything running on the GNS VM, because both the Windows Server VM and Cloud-1 are hosted on my physical machine. Note that anywhere Windows Server appears, it's with a red square at this point, because the VM is turned off.

Now. What I've done by connecting the network interface on Windows Server, to my physical interface through the Cloud, is created a "link" where Windows uses its virtual network interface, and GNS3 transparently takes that traffic and routes it out through the physical interface. When traffic comes back, it works in reverse - GNS3 takes it from the physical interface, and passes it to the VM, and as far as the VM's concerned that traffic came straight from its virtual interface.

All right. The green "Play" button up top will start up all the virtual nodes on the network...

After hitting Play, GNS3 starts up the Windows 2016 Server VM for me.

Moment of truth...

Well. I wasn't expecting it to come back in IPv6, but if I ping an IPv4 address, I get a response back. My VM's connected to the Internet through GNS3!

Next step

Next step's going to be adding a virtual Cisco router into the mix and confirming that GNS3 is fully working.

But for now, Heroes of the Storm calls...

Day 3 - Integrating GNS3 and the VMWare environment

Introduction

It's been a couple weeks, I've been busy getting ready to separate from the Air Force. But I'm on terminal leave now, and I've got nothing but free time!

What's Next

I've never been great at focusing on one thing at a time. Especially in the last couple months, when I've been at work and not able to access my VM environment, so I was just reading e-books on certifications. Unfortunately, with no access to a test environment, I can only read so much about a single topic with no hands-on practice before I have to switch tracks and read about something else.

With that in mind, I ended up switching tracks for a little bit to read my CCNA study material.

As with other certification projects, CCNA is hard to train for without a lab environment. GNS3 - the network simulator I mentioned earlier on - can provide that environment. But, I didn't want to branch off into a completely separate project. So I found myself wondering... can I integrate my current virtual environment with GNS3?

As it turns out... I can.

Getting Started

GNS3 basics

As a reminder, GNS3 is a simulator capable of running Cisco IOS images as virtual machines - except in this case, the "VMs" are network devices rather than traditional computers. (I'm going to call them VNDs just to avoid confusion.

I already installed GNS3 using pretty much all the default options (minus the numerous pleas to install Solarwinds stuff.)

When you first start GNS3, you have to configure it.

GNS3 offers a few different ways you can run VNDs:

1. The first option entails running a custom GNS3 Linux VM on your local machine, and your VNDs will run inside of that.
2. The second option is to have no GNS3 VM, and run your VNDs directly on your host operating system. According to my research, Windows has problems with emulating certain VNDs, which is why option 2 limits the types of VNDs you can run.
3. The last option is to connect to a remote GNS3 server, which hosts all your VNDs.

I'm already virtualizing everything, and I like functionality, so I went with option 1.

On the next screen, I went with the default options for the GNS3 server.

Next, assuming you went with option 1, GNS3 asks how you want to run the GNS3 VM.

You have two virtualization software options: VMWare, and VirtualBox.

As far as free stuff goes, you have a couple options: VirtualBox is free, as is the slimmed-down version of VMWare called VMWare Player. As you might expect, though, free comes with a couple drawbacks - VirtualBox doesn't support nested virtualization, which means it may run VNDs slowly. VMWare, being a free edition, doesn't let you do some really helpful things (like run multiple VMs at once.) If you're not planning on running any other VMs, though, VMWare Player should work fine for running the GNS3 VM by itself.

Anyways. I have VMWare Workstation, so I went with that one.

The neat thing about VMWare is that it has an interface for external software - like GNS3 - to integrate with it. So once you download the pre-built GNS3 VM from GNS3's website, all you have to do is double-click it, and it'll automatically import itself into VMWare, and GNS3 will be able to see it and interact with it.

I already did this, which is why "GNS3 VM" is already selected. I left the vCPU and RAM size alone, and finished configuration.

Starting GNS3

After you finish setup, GNS3 with automatically start its VM within VMWare.

At this point, I hit a snag, in the form of this dialog box, which kept going up to 100% and then resetting:

Progress bars have percentages for a reason - why do so many software companies defeat the purpose of a progress bar by filling it with false information? But I digress.

Meanwhile, over in my GNS3 VM, I had this worrisome message:

It appeared that GNS3 was trying to connect to its VM, but its VM for some reason was not connected to my home network.

As suggested, I went into the Networking configuration screen in the VM, and was warned that the server would reboot at the end of the process. Okay, sure.

Of course this couldn't just be simple. Oh well, at least I get to use nano instead of vi.

Okay. The file specifies that eth0 is the "host only" interface, and it appears to be set to use DHCP.

"Host only" is a type of VMWare virtual network interface which essentially creates a private LAN between a VM (or several VMs) and its host machine. VMWare should run a DHCP server on this private LAN to assign IPs to any VMs that ask for one.

In this case, however, it appears that this isn't happening.

Next step was to check that the VM itself was configured correctly:

As far as I know, the order that the adapters appear in the VM settings is the same order that they'll appear to the host machine (eth0, eth1, etc.) - so eth0 is in a host-only network as it should be.

As promised, once I closed out of nano, the VM rebooted. Fine.

Once it came back up, I got the same message.

This time, I decided to pull up a shell from the menu and see if I could figure something out from there.

`ifconfig | less`

Okay. Definitely not getting an IP address. Time to dig through log files... GNS3 keeps the ones I'm interested in in /var/log/upstart. In particular, I'm interested in network-interface-eth0.log - which had some helpful information at the end:

For whatever reason, VMWare appeared not to be responding to DHCP requests from the VM.

VMWare runs a service on the host machine called - imaginatively - "VMware DHCP Service." I'd had issues with VMWare services on the host machine before, so I restarted the service to see if that helped, then restarted the VM itself.

It didn't.

I did some more digging, and discovered an annoying quirk of VMWare's virtual network feature:

VMWare has two virtual networks named VMnet0 and VMnet1. They cannot be deleted or renamed.

As it turns out, VMnet0 is the default virtual network for VMs where a "bridged" connection (VM connected directly to the external network) is selected, and VMnet1 is the default virtual network for VMs where a host-only connection is selected. This isn't noted anywhere in the virtual network editor.

What had happened was, I got tired of trying to remember which VMnet was which (remember, they can't be renamed) so I just set them both to host-only, disabled DHCP, and created additional virtual networks that I COULD rename.

Except, now, my GNS3 VM was trying to use VMnet1 by default, which was a "dead" network with DHCP disabled.

So at this point, I deleted my custom network, reset VMnet0 and VMnet1 to their original settings, and rebooted the GNS3 VM.

Finally.

I went back to GNS3, and tried to finish configuration again... shocking, it immediately connected to the VM and asked me what I wanted to do first:

What's Next

Next, I need to create VND "templates" and add my VMs to GNS3. That falls under "customization," so it's going to be the next entry.

Day 1.2: VPN troubleshooting

Starting point

This entry has been a couple days in the works. Mainly because I didn't want to be writing up everything I was doing while I was also trying to Google and troubleshoot.

So after all my hard work trying to set up a VPN tunnel, I realized that my local network at home (where my virtual W2016 server had its "external" IP) used part of the same IP range (10.0.0.0/24) as my VPC (10.0.0.0/16).

Moving ahead

I took the easy way out and changed my home network to use a 172.* private address range instead.

Unfortunately, my VPN tunnels still weren't working. EC2 showed them both down. Tracert'ing shows that my VM was trying to route VPC-destined packets into my local network instead of over the VPN tunnel.

I wasn't totally sure what I did last night, so I decided to wipe out RRAS and related roles on W2016 and start from scratch.

Didn't help either. At this point I realized I didn't know nearly enough about IPSec to understand what I was doing, so I put it on hold.

By a lucky coincidence, I happened to be reading about IPSec in my CCNA study guide yesterday, which got me at least a basic understanding of what I was actually trying to do.

Armed with this, I gave it another shot last night.

First realization: I have a NAT router between my home network and the Internet. This is a problem since IPSec is stateless at the network/transport layers. I added port forwarding to the router to make sure the IPSec packets were able to make it back to the VM.

Still no dice. For reference, here's what my setup at home looks like right now:

Don't hate - I made this in PowerPoint, from memory, at work.

So I started running Wireshark on my host machine to watch for packets going to the AWS gateway.

I discovered that packets were making it to the local LAN, but with a source address on the 10.* network. It was at this point that I realized that I never set up NAT on the Win2016 VM like I'd intended (which would have made the Win2016 VM the single entry/exit point for traffic going in/out of the VPN) - so I went ahead and did that. I also set up a static route on the VM to route traffic destined for 10.0.0.0/16 to itself.

Finally, after watching Event Viewer and the Windows Firewall monitor, it looked like I was having some limited success! Windows was negotiating with the VPN gateway and setting up the tunnel successfully.

Unfortunately, watching Wireshark... I noticed that after the VPN tunnel was established, all the data packets headed for the VPN got an ICMP "Port Unreachable" response.

At this point, I found myself wondering if AWS was returning that response as a "translation" that something was misconfigured on the other side of the VPN gateway. (The port shouldn't have been actually unreachable since that's how the tunnel was set up.)

Minor correction to the graphic: at this point, I still had my VM LAN set up as 10.0.2.0/24. I figured I should probably change this to make sure I wasn't having more subnetting issues, so I switched the VM LAN over to 10.1.0.0/16.

For some reason, at this point, the IPsec rule stopped working. I called it a night since it was past midnight.

That's where I'm at now. More to come when I get home...

Day 1.1: Implementing a VPN connection to an "outpost."

Getting Started

VMWare Setup

First thing I need to do, like I described in the design, is set up VMWare with a "virtual network" and then give one VM the ability to talk to the outside world.

Added a "host-only" network, 10.0.2.0/24.

My W2016 VM was already built, so now I just needed to configure it as a go-between:

VM configured with two network adapters: one on the virtual network I just created, the other sharing an IP address with my physical machine.

Once I started up the W2016 VM, it was a little confused, since its configuration wasn't what it was last time it was powered on.

I renamed the connections to match their respective "sides." One of them isn't working, I'm not sure why. I'll tackle configuring the INTERNAL side first.

I've decided my "outpost" subnet is going to be 10.0.2.0/24 and my "hub" is going to be 10.0.2.100. There's no default gateway yet. For now, I'm going to have it use Comcast's DNS servers.

Now to tackle the other problem: Google suggests that this is a problem with using NAT for that interface, so I switched it over to "Bridged." Problem solved.

Setting up the VPC for VPN (!)

I basically just followed this guide: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/SetUpVPNConnections.html to set up the VPN connection itself (using static IP addressing.)

---

Okay, after all this, I found a major flaw in my plan.

My VPC address range is 10.0.0.0/16.

My internal network here at home is 10.0.0.0/24.

The VPN tunnels aren't working because W2016 is trying to forward traffic destined for the VPC, out over my local network instead of through the tunnel.

I think I'm gonna work on this some more tomorrow.

Day 1: Designing a VPN connection to a VMWare "outpost."

Starting point

As of this point, I have a functioning Windows 2016 domain controller and DNS server, which is the starting point for the rest of the network.

Next objective

I have a VMWare Workstation Professional install running on my local machine with a bunch of workstation-type VMs installed inside. As far as testing out my domain's abilities to centrally manage a bunch of different systems, I'd like to be able to use these VMs - because EC2 instances mostly run server operating systems.

One of my local VMs is a Windows 2016 Server, which is perfect! It can serve as a local domain controller for my VMs.

Of course, there's one problem: my VMWare install is running here, and my primary domain controller is running in AWS.

So that's today's problem: establishing a VPN tunnel between my W2016 VM, and my VPC running on AWS.

(This is an unusual scenario that most people won't need or want to do, but I want to, so...)

Design

There's a few problems I need to overcome:

1. My local machine is on a Comcast residential connection, and can't be relied on to have a static external IP address. 
2. My W2016 server is running inside a virtual machine, on a physical machine, which is behind a NAT firewall.

The solution to #1 is pretty straightforward: it means the VPN tunnel will have to be initiated from my end, every time.

#2 is more complicated. I don't want my VMs to be on my local network, I want them isolated in their own virtual network. But I also need them to be able to talk through the VPN.

The solution: VMWare will allow me to create a virtual network with no direct connectivity to the outside world. All the VMs will go on this network. The W2016 VM, though, will get a second virtual NIC that has connectivity to my local network, and from there to the outside world - through which it can establish a VPN tunnel.

I'm not certain at this point whether there will be any ill effects from maintaining two separate domain controllers that don't stay on 24/7. But we'll find out.

Day 0.2: AWS Design/Setup

Getting Started

I'm writing this section retroactively, since I already did most of this before starting this blog.

Building a VPC

Intro

VPC - Virtual Private Clouds - are basically private networks (existing inside the standard private class A/B/C IP ranges) inside of which you can launch EC2 instances. You can subnet VPCs, create custom routes and ACLs between them - pretty much anything you could do with a physical network.

I decided to use 10.0.0.0/16 as my private network to give myself room to subnet (and because I knew if I went with class B, I'd never be able to remember which 172.* network I settled on.)

When I did this initially, I created a single subnet that took up the entire /16 address space of my network and started putting machines in there.

This was a mistake. Afterwards, I realized I wanted to make actual /24 subnets, but at this point I already had EC2 instances assigned to the /16 subnet and couldn't figure out how to get rid of it... so at this point I just gave up and started over from scratch with a new VPC. You live, you learn. Fortunately, I hadn't done much at this point.

Final(?) Design

I settled on 10.0.0.0/16 as my VPC network, with a single subnet of 10.0.0.0/24 to start. Since I was going to start out building a domain controller, by default, 10.0.0.0/24 is now my "core" subnet where critical servers are going to live.

Big takeaway: don't create a subnet that takes up your entire VPC if you want to be able to create smaller subnets later on.

Implementation

VPC Creation

First thing to do is create the actual VPC. This is pretty simple - all you need is the CIDR range of the network (though it's helpful to give it a name, too.) You can also specify that you want dedicated hardware for it, but I don't need or care about that. I also don't care about IPv6, at least not right now.

New VPC: 10.0.0.0/24

Most of the default settings (ACL, routing table, DHCP options) for a new VPC are perfectly fine, with one exception: new VPCs have no "Internet Gateway," which means they have no way to reach the Internet. (That might be okay if you only want this VPC to be reachable from other VPCs, but for me, that just means I can't reach it to set it up.)

Adding a new Internet gateway is easy. Like, really easy. You go to the Internet Gateways section of the VPC console and create one. You don't even have to give it a name (though you probably should.)

Route Setup

The easiest way to get at your VPC's routing table is to open up your VPC listing screen, select your VPC, and click the routing table in the window at the bottom.

Select the routing table from the list that appears, and in the bottom window, select "Routes." By default, you'll only have one route, for your VPC's CIDR address with a target of "local." Select "Edit," and add a new route for destination 0.0.0.0/0, with a target of the Internet gateway you selected in the previous step.

Routing table with 0.0.0.0/0 route added to my Internet Gateway.

Adding a Subnet

One last step: creating a subnet within your VPC. Add a subnet from the Subnets category of the VPC console. You can (should) specify a name, but you must specify the VPC you want to add the subnet to and the CIDR address of the subnet itself. Availability zone doesn't matter - that's for people wanting to design redundant EC2 systems.

Again, I don't recommend creating a subnet that takes up your entire VPC unless you know for sure you're not going to want to create any other subnets later on.

Subnet 10.0.0.0/24.

You now have an Internet-connected VPC with a subnet, ready for EC2 instances.

Creating EC2 Instances

Launching an instance

The first step is to build the hardware requirements for the instance and then save it to create the instance.

From the EC2 console, select Instances, and Launch an Instance. You'll first be prompted to select the operating system configuration to install on the instance. There are a whole bunch of operating system options, with various customizations. For my initial setup, I only needed a basic Windows 2016 Server setup.

The next important consideration is what type of instance you're going to run; they come in various configurations, some specialized for memory, some for storage, some for computing power. I just needed a generic instance, with enough memory to run W2016, so I opted for t2.micro.

On the next screen, there are a couple important options: Network, where you specify the VPC you want the instance in, and Subnet, where you specify the subnet within that VPC. Slightly further down, under Network Interfaces, you have the option of specifying the primary IP address that will be assigned to that instance.

On the next screen, you specify how much storage space you want the instance to have. Different operating systems/configurations have different minimums; the minimum for a W2016 Server Base is 30GB.

On the next screen, you can add your own "tags" to the instance. Don't need to here.

The next screen is important. This is where you can specify the firewall rules that will apply to your instance right away. Since the Internet is full of infected systems automatically scanning for other systems to infect, you want to minimize the chance that your system will get infected before you've had a chance to harden it. With that, two things to keep in mind. First, out of the box, you should only allow a connection to the service you're going to be using to configure the machine (typically RDP for Windows and SSH for Linux.) Second, for that service, you should (at least initially) restrict access to the IP address or subnet that you're going to be administering the machine from. I opted to use the /16 of my own IP address just in case it changed, which still restricts access to a relatively small subset of random Comcast users.

Security group for my "hub" server.
(Note: this screenshot was taken after I'd already patched the machine and set up a DNS server.)

Summary description of my hub EC2 instance.
(Note: Elastic IP is already assigned.)

Adding a Public IP

AWS assigns public IPs with something called "Elastic IPs."

The idea is, you get assigned a public IP address from Amazon's pool, which you can then assign and swap between your EC2 instances at will (though you probably don't want to do this.)

Since IPv4 addresses are a limited commodity, and they can't be reused as long as they're assigned to your account, Amazon will charge you (not a lot, but they will) any time they're not being used (i.e. attached to a running EC2 instance.)

Creating Elastic IPs is easy, though. Go to the Elastic IP screen of the EC2 console, and allocate a new address. Next, right-click the address, and choose "Associate Address" to tie the Elastic IP to the private IP address of an EC2 instance.

You can verify the configuration by looking at the configuration of the Network Interface attached to the EC2 instance.

Network interface with a public IP attached.
(Note: this instance has two "private" interfaces. The primary is attached to the Elastic IP and is publicly accessible - the other is not and can only be accessed from the inside.)

Summary

So far, we've:

• Created a VPC
• Added an Internet gateway to the VPC, and made it the default route for non-VPC destined traffic
• Created a subnet within the VPC
• Created an EC2 instance
• Restricted inbound access to the EC2 instance
• Created a public IP address and attached it to the instance.

Next post is setting up the instance as a domain controller.