Tag: networking

VLAN and Routing with Unraid

VLANs had me confused and running in circles for a while when I was first setting them up too. My understanding of things may not be entirely correct or the “right” way of doing things, but it worked for me. I don’t have experience setting up VLANS in the Unraid interface, but my experience getting VLANs working may help you notice something you overlooked.

I believe you need switches and a router that support VLANs, also known as 802.1q. The switches certainly need support for VLANs and I believe the router may need it to route traffic between VLANs (e.g. from VLAN 4 to VLAN 9), perform network management things like DHCP, and access the Internet. Many consumers routers and basic unmanaged switches don’t support VLANs. Third-party firmware like OpenWRT may be able to add VLAN support to consumer routers. I’m not sure what a “smart unmanaged” switch is, but if it doesn’t have some sort of an interface, be it Web, software, serial/RS-232, or ssh/telnet based, it isn’t smart enough to support VLANs; all VLAN configuration is performed on the device itself via some sort of interface. Check the spec sheets on your gear.

I ended up using Netgear GS108Tv2 and GSS116E switches with a pfSense router running on a Dell 780 SFF PC with a I350-T2V2 network adapter. The fancy network adapter isn’t required. The 116E switch has basic “port-based” configuration, but the 108T doesn’t, so I used “advanced” VLAN configurations.

The first major concept to understand is that network traffic doesn’t have VLAN tags until you turn on VLAN support. Traffic on VLANs has extra data added to it, (the 802.1q header), that requires routers and switches to understand VLAN-formatted traffic.

The second major concept to understand is the Port VLAN ID (PVID). It appears to be the default VLAN ID for a port.

The third major concept to understand is VLAN membership. A port is a member of a VLAN if it’s marked as “tagged” or “untagged” on a VLAN. Most devices, e.g. PCs, game consoles, iPads, etc., don’t understand VLANs and so their traffic does not contain a VLAN tag; their traffic is “untagged” when entering the network. “Untagged” ports assign the PVID of the port to the traffic, giving it the VLAN information needed to move on a VLAN network; traffic inherits the VLAN ID from the port. My networked devices are all “untagged” on once VLAN, making them a member of a single VLAN.

“Tagged” ports appear to be designed to move traffic that is is already tagged. This could theoretically come from a device that understand VLANs or be traffic from an “untagged” port that had a tag added by the switch. Cisco uses a technology called “trunk” ports for passing traffic between switches and routers that Netgear doesn’t have. I use “tagged” ports to accomplish this task. My “trunk” ports are tagged in all VLANs, making them a member of all VLANs and allowing them to communicate with all VLANs while passing traffic between switches and routers.

All my networked device are on “untagged” ports but they they inherit a VLAN ID from the port; they become “tagged” by the switch rather than the original device. Once the traffic from a device is tagged by the switch, it can communicate with any device on the same VLAN. Communicating with devices on a different network switch or communicating with devices on the Internet requires the “trunk” ports that are tagged in multiple VLANs.

I set up VLAN 1, 4, and 9; 1 is used for network management, 4 is for my PCs and such, 9 for my Unraid server.

My only experience is with the Netgear stuff, so some of the terminology may be different with other brands.

So if Port 1 connects the switch to the router, Port 1 would bet marked as tagged on VLAN 1, 4, and 9 in my setup, making it a member of VLAN 1, 4, and 9; this makes it something like a “trunk” port between the switch and router and allows all the traffic can get upstream to the router as needed. My “trunk” ports also got a PVID of 1; they always tagged traffic, so the PVID may not matter.

If Port 2 is connected to my desktop PC, it would get a PVID of 4 and is untagged on VLAN 4 only. This allows the port to only communicate with other devices on VLAN 4.

If Port 3 is connected to my laptop, it would get a PVID of 4 and is untagged on VLAN 4 only. This allows the port to only communicate with other devices on VLAN 4.

If Port 4 is connected to my Unraid server, it would get a PVID of 9 and is untagged on VLAN 9 only. This allows the port to only communicate with other devices on VLAN 9.

The fourth major concept is inter-VLAN routing. My PC and laptop in the example above can talk to each other because they’re both on VLAN 4 and can talk to the router via the trunk on port 1. The Unraid server can talk to the router. However, members of VLAN 4 can’t talk to members of VLAN 9. I remedied this with firewall rules in the router. These rules allow me to control which devices (IP addresses) and services (ports) on VLAN 4 can communicate with which devices and services on VLAN 9. I believe this is a reason why the router needs VLAN support – you’re routing between VLAN networks (e.g. 192.168.4.100 to 192.168.9.10). The router may also need to understand the VLAN-formatted packets so it can strip off the VLAN formatting before forwarding it to the Internet.

So I added firewall rules in pfSense to allow my PC and laptop to access the Unraid web UI, ssh, file sharing ports, Plex ports, etc. of my Unraid server.

See more here

Connecting an Azure WebApp to a SQL Server VM inside a VNet

This article is about connecting an Azure WebApp to a SQL Server VM which is hosted inside an Azure Virtual Network. Typically a SQL Server VM would be hosted inside an Azure Virtual Network (VNet)  to isolate it from the internet by blocking all inbound and outbound internet traffic using a Network Security Group (NSG). In this scenario, connectivity  to the SQL Database is achieved by using the new VNet Integration feature found on the App Service component. Using this feature removes the requirement of an App Service Environment (ASE) for the WebApp thus reducing overall hosting costs.

Using VNet integration provides private outbound access from your App Service to resources in your VNet using the RFC1918 internal IP address allocation range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) by default.

 Scenario

A web application is hosted in a WebApp which requires a connection to the SQL Database hosted inside a VNet.

The network topology of this scenario is shown below which uses the Regional VNet Integration option where both the WebApp and SQL VM are in the same region. Here we have a VNet called LAN-VNET which has two subnets, one for the VNet Integration used for delegating called interdelg-subnet and the other to host the SQL Server VM called vm-subnet.

Configuration Walkthrough

The following are the sequence of steps used to setup VNet Integration between a Web App and SQL Server with the assumption the SQL Server VM is already hosted inside a VNet.

1. Adding a VNet subnet

2. Provisioning  an AppSvc Plan

3. Provisioning  a WebApp

4. Setting up the VNet Integration

5. Validating SQL Server Security Settings

6. Testing connectivity to the SQL Server

7. Updating the Web App SQL Connection String

1. Adding a VNet Subnet

A dedicated subnet used by the VNet Integration feature is required to be added to the existing VNet hosting the SQL Server VM. The IP range should match the maximum number of AppSvc plan instances when fully scaled out as each instance would require a IP address. For this scenario I will be using a /27  prefix giving a total range of 32 address, however  5 address are used internally by Azure leaving 27 usable addresses for each plan instance.

2. Provisioning App Svc Plan

To use VNet Integration, you will need to provision an App Service plan using newer V2 scale units. Note if you are currently using V1 App Services, you will need to provision a new plan using V2 and migrate you apps to this new plan.

To confirm if you have selected the newer V2 App Services, the Premium plans should be shown as P1V2, P2V2 and P3V2. Here I will be using a Standard Plan S1 for this scenario highlighted below.

3. Provisioning Web App

Create a new Web App and ensure it is in the same region as the VNet. Also ensure you have selected the  App Service Plan you created above.

4. Enable VNet Integration

Under the Web App that was provisioned above, click on the Networking menu item to view the networking options and then click on “Click here to configure” under the VNet Integration heading.

Go to your app and click on networking. Click on vnet configuration;

Once the VNet Configuration form opens, click on the “Add VNet” to open the Network Feature Status blade. Select the VNet that hosts the your environment and then the Subnet that was created earlier for the VNet Integration. Then press OK to save the changes.

After you hit OK, the VNet Integration should be connected and ready for testing the connectivity. Remember the VNet Integration will route all outbound RFC1918 traffic from the WebApp into your VNet.

5. Validating SQL Server Security Settings

To reduce the surface area of attack, ensure the SQL Server can only accept connections within the VNet. This is done by setting the “SQL connectivity” option to Private (within Virtual Network) under the Security menu of the SQL Virtual Machine.

Also check the NSG attached to the SQL Server VM to ensure there is a rule to disable all outbound internet traffic. If there is a inbound rule called default-allow-sql as highlighted below, it is advisable to delete this rule if not required. This inbound rule default-allow-sql is normally created when the security on the SQL Server VM allows SQL connectivity via Public (Internet) connections.

6. Testing connectivity

To check connectivity between the Web App and the SQL server, we can use the  tcpping command from a console window. Go to the Web App that was created previously and click on the Console menu item to open a console window similar to below.

In the console window type the command tcpping <sql vm private ip address>:1401. All going well you should get a reply similar to that below where 10.0.2.4 was the private IP address of my SQL Server VM using the default port 1401.

For some strange, if tcpping doesn’t work, check Inbound Rule in your server windows firewall for SQL Server Database Engine (Tcp-in) port;

Sometimes portal changes doesn’t apply to database. why? don’t know.

Make sure that ICMP for IP is enabled on your server firewall otherwise ping will fail.

7. Updating the Web App SQL Connection String

Once the connectivity has been verified, the next step is to update the connection string on the Web App to use the private IP address of the SQL Server VM. Typically the connection string should look something like this:- Server=10.0.2.4;Database=MyDb;User Id=myusername;Password=mypassword;MultipleActiveResultSets=true

After the connection string has been updated to use the private IP address, you should be able to test your application.

VNet Integration provides an easy and cost effective solution to access databases hosted within a VNet without resorting to a dedicated  ASE. Also using rules on the NSG applied to the SQL Server VM provides the capability to block all internet traffic and allow only RFC1918 internal addresses to have access.

Resource

https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet