Azure Routing for EVE-NG

Reading Time: 4 minutes

This time I write a small post about my Azure Routing for EVE-NG and how to get this working with my Azure Gateway to access nodes on the EVE-NG.

In a previous post, I wrote about the IPSec tunnel from my home lab to Azure. To get access to the nodes on the EVE-NG VM I need to install some additional routing in Azure. It took me a while to figure out what to do, but in the end, it was a very simple task.

Create a new Routing Table

First, you create a new Routing Table in Azure. Just search for “Route tables” and create a new one with the click on “Create”:

Azure Routing - Create Route Table
Azure Routing – Create Route Table

Creating the routing table is easy, just select the “Subscription” and “Resource group”. I use the one, which includes my EVE-NG server as well. Also, select the “Region” and of course, enter a “Name”. If you use an Azure Gateway also propagate those routes as well. “Review + create” the new routing table.

Now, open the routing table and go to “Subnets”. Here you “Associate” the required subnets to the routing table. In my case, this is the subnet with my gateway and the subnet with my EVE-NG VM:

Azure Routing - Associate Subnets
Azure Routing – Associate Subnets

The important step is to create the route. Go to “Routes” and “Add” a route to the table:

Azure Routing - Add Route
Azure Routing – Add Route

There are just some things to look at. Make sure, you select “IP Addresses” for “Address prefix destination” and enter your internal subnet. This is the one you use to attach nodes to, on your EVE-NG server. For the “Next hop type” select “Virtual appliance” and enter the IP of your VM in the “Next hop address” field. Afterward, click “Add” to add this route to the routing table.

To check if this worked out go to the EVE-NG (or whatever VM you have) and select the network adapter. In the lower “Help” section you find the “Effective routes” option. Use this to see all the routes applied to that interface:

Azure Routing - Effective Routes
Azure Routing – Effective Routes

The first two entries in the routing table represent my home network. They are learned from the gateway. The third one is the route created above. So from that, it looks fine.

To allow the interface to route traffic you need to enable IP forwarding. Go to the “IP configurations” section and enable “IP forwarding”:

Azure Routing - Enable IP Forwarding
Azure Routing – Enable IP Forwarding

That’s all you need to access a subnet on your EVE-NG server.

Enable Routing in EVE-NG

This part is only for EVE-NG. My setup in EVE-NG is as follows:

The server is one IP, assigned by Azure. This IP is also used to access the internet from EVE-NG itself and for notes running on EVE-NG. To allow this, I use one of the cloud networks in EVE-NG. This cloud network is in the subnet, which is forwarded to EVE-NG using the routing table from the part above. In my case it is pnet2 (cloud2):

pnet2     Link encap:Ethernet  HWaddr b2:f6:11:f6:48:ba
          inet addr:172.16.2.1  Bcast:172.16.2.255  Mask:255.255.255.0
          inet6 addr: fe80::b0f6:11ff:fef6:48ba/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1216 (1.2 KB)

I created some rules to NAT everything going through the EVE-NG server on the Azure network interface. The trick is to exclude everything with the destination to my homenetwork:

# Generated by iptables-save v1.6.0 on Thu Feb 10 08:33:46 2022
*nat
:PREROUTING ACCEPT [2:128]
:INPUT ACCEPT [2:128]
:OUTPUT ACCEPT [190:11419]
:POSTROUTING ACCEPT [6:360]
-A POSTROUTING -d 10.0.0.0/8 -o pnet0 -j RETURN
-A POSTROUTING -d 172.16.0.0/12 -o pnet0 -j RETURN
-A POSTROUTING -d 192.168.0.0/16 -o pnet0 -j RETURN
-A POSTROUTING -o pnet0 -j MASQUERADE

The last 4 lines did the trick. The last one is NATting everything to the Azure Interface. The 3 entries before, exclude every subnet I use in my home lab and in Azure. This allows me to access nodes, connected to the cloud2 network, directly. This makes it much easier to work with nodes, which have a web interface, or even to access them via SSH. I usually connect my “management” connection from the nodes to this network and keep all the test traffic locally on the server.

If you find this post useful, leave me a comment and share your feedback with me. If you would like to do me a favor, share this post with your friends and social media contacts. This would really help to make this blog more popular and help others to find the information above more easily using search engines.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: