Skip to content

Explore Hybrid Environment

Now we are ready to explore the simulated on-premises environment.
VPN established state

Explore the simulated datacenter environment

We've now launched a simulated datacenter environment that consists of a customer gateway, a web application server, and a DNS server. Let's make sure that the components are working before we move on to connecting this to our AWS environment.
1. On the Customer Gateway instance check which DNS server the host is using by examining the /etc/resolv.conf file. 

cat /etc/resolv.conf
  1. Take note of the "nameserver" line, which should point to 172.16.1.200 which is the IP address of the on premise DNS Server created by CloudFormation template rather than the default VPC name server on 172.16.0.2. 
sh-4.2$ cat /etc/resolv.conf  
; generated by /usr/sbin/dhclient-script  
search example.corp  
options timeout:2 attempts:5  
nameserver 172.16.1.200
  1. Test the application server. In our simulated datacenter environment, we use the internal domain name example.corp and the application server has a hostname entry for myapp.example.corp created in the DNS server. We can test that the application server is up and running by using the curl command: 
curl http://myapp.example.corp
  1. If your application server is working properly, you will see a response of "Hello, world." 
sh-4.2$ curl http://myapp.example.corp  
Hello, world.
  1. Terminate the Session Manager connection.

Test the VPN connection from AWS to the simulated datacenter network.

Now that our VPN tunnel is up, we can test connectivity from the AWS environment, via the Transit Gateway, to our simulated on-premises environment. Recall that our on-premises environment contains an application server and a DNS server. The application server has a DNS A record in the on-premises DNS server for the myapp.example.corp hostname. In this section, we will verify connectivity between the AWS and simulated datacenter environments and test that we can connect to the application server.

  1. In the EC2 Dashboard select Instances
  2. Select the check box next to VPC A Private AZ1 Server and click Connect to start a Session Manager console
  3. Test connectivity to the on premise application server's private IP address of 172.16.1.100 
ping 172.16.1.100 -c 5  

sh-4.2$ ping 172.16.1.100 -c 5  
PING 172.16.1.100 (172.16.1.100) 56(84) bytes of data.  
64 bytes from 172.16.1.100: icmp_seq=1 ttl=253 time=2.90 ms  
64 bytes from 172.16.1.100: icmp_seq=2 ttl=253 time=2.28 ms  
64 bytes from 172.16.1.100: icmp_seq=3 ttl=253 time=2.07 ms  
64 bytes from 172.16.1.100: icmp_seq=4 ttl=253 time=2.17 ms  
64 bytes from 172.16.1.100: icmp_seq=5 ttl=253 time=2.28 ms  

--- 172.16.1.100 ping statistics ---  
5 packets transmitted, 5 received, 0% packet loss, time 4005ms  
rtt min/avg/max/mdev = 2.077/2.345/2.909/0.293 ms
  1. Test the application server using curl: 
curl http://172.16.1.100

If your VPN connection is functioning correctly, this command will return "Hello, world." from the application server. 

sh-4.2$ curl http://172.16.1.100  
Hello, world.
  1. Next let's verify that the AWS EC2 instances can reach the on-premises DNS server if we query it directly by using the IP address and the dig command to query for myapp.example.corp: 
dig @172.16.1.200 myapp.example.corp

Your query should return an A record for the on-premises application server, similar to the following: 

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> @172.16.1.200 myapp.example.corp  
; (1 server found)  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2272  
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;myapp.example.corp.            IN      A  

;; ANSWER SECTION:  
myapp.example.corp.     60      IN      A       172.16.1.100  

;; AUTHORITY SECTION:  
example.corp.           86400   IN      NS      ns1.example.corp.  

;; ADDITIONAL SECTION:  
ns1.example.corp.       60      IN      A       172.16.1.200  

;; Query time: 7 msec  
;; SERVER: 172.16.1.200#53(172.16.1.200)  
;; WHEN: Tue Sep 21 05:01:56 UTC 2021  
;; MSG SIZE  rcvd: 97
  1. Test the application server by using the hostname in the curl request: 
curl http://myapp.example.corp

Important

This should fail. We will receive an error message "Could not resolve host" because DNS has not yet been configured to allow the AWS instances to resolve names hosted on the datacenter's DNS server. 

sh-4.2$ curl http://myapp.example.corp  
curl: (6) Could not resolve host: myapp.example.corp
  1. Terminate the Session Manager connection.

Congratulations you've shown that there is connectivity in place from AWS to both the application server and DNS instance running in the on-premise environment. We will address hybrid-DNS in the next section that will allow DNS resolution of on-premise hosts from AWS.

VPN traffic from AWS