I know nothing. This is the feeling I get when I approach a brick-wall in my studies. I can literately feel the blood rushing to my face. Perhaps I should go for a walk, a smoke, have another snack…. After i shake the urges for procrastination and dig a little deeper I suddenly find something I didn’t notice before. As I hack away at that little something it turns my brick-wall into a treadmill. Before I know it I’m blazing through my goals successfully and with new insight.
Once again back on the GNS3 lab I found a new need I didn’t anticipate. Internet. Yeah you can hack away all day with the tool Kali has prebuilt. Eventually you’re going to want to play around more than just with pre-built tools. Adding Internet seemed logically simple enough. Add an interface (eth1) to my attack box and have it connect to the internet. I can just disable that interface when i want back on my local network. I had studied enough networking to realize I’d probably need to forward something and set up MASQUERADING. The technical details for the most part were apparent. Of course there are the little things.
In short I needed to set up a TUN/TAP on my linux host (reference). Then access that TAP from GNS3 via a cloud entity. This requires GNS3 run in root. While that doesn’t sound like a big deal; it’s a big deal. After your GNS3 is nice and configured on a regular user, and all the saved topologies are nice and storied in their home user account, you run in root. Nothing will be configured. Nothing.
I humor the idea of starting over. Turns out none of my Virtual Machines in Virtual Box are available either. Know why? Yep I got to run VirtualBox as root too! What a mess. You can export the VM’s you need and then import them back into rooted VBox. This works fine but is time consuming info to find when it’s a surprise.
Now I got my VM’s back in VBox. I got them set back up in GNS3. My LAN works with Attacker/Victim/DNS/Switch. When I go to set up my cloud I can set the NIO_TAP as an interface. I get on my 2600 router console via GNS3 and quickly configure the router to speak with the TAP. Everything is great I can even hit 220.127.116.11 thanks to setting up ‘ip route 0.0.0.0 0.0.0.0 172.16.1.1’ (172.16.1.1/30 is my TAP0 -> Eth0/0 connection). I continue to configure the router Fa1/0 interface to communicate back to my Attack system (which I want to update) on a second NIC eth1. This works out great as well. The eth1 nic is talking well with the Fa1/0 on the router. I can ping the eth0/0 on the router 172.16.1.2. But I can’t ping the 172.16.1.1 along with the rest of the internet. This was my brick wall.
Identifying that my problem was getting form the router to the local machine was critical. From the router I had no issues hitting any address in the wild. Six to Seven hours later I found out what I was missing.
R1(config)#access-list 10 permit any
R1(config)#ip nat inside source list 10 interface Ethernet 0/0 overload
R1(config-if)#ip nat outside
R1(config-if)#ip nat inside
The one thing not getting configured was this ip nat inside source list command. If I had been more thorough in reading Jesin’s Blog about this I would have seen this much sooner.
“By now we have configured one GNS3 router to connect to the internet, if you connect more routers to this router connected to the cloud you will find that they are not able to communicate with the internet. This is because the physical machine does not know how to route the packets generated by the other routers of GNS3. The best solution for this is to perform Source NAT on the router connecting to the cloud. ” –Jesin’s Blog
While in Jesin’s example they did use routers coming into R1 which was then going to the could. This isn’t much different from my scenario. Once I configured my R1 with the access-list and overload settings things worked like I needed them to. Now off to further understand what these things do in more technical detail.