News Blame The Spammers

4 Comments

When I first started this blog I wanted those that visited here be free to leave comments without the need for said comments to be approved before they were posted. Unfortunately the amount of spam I’m getting now exceeds my ability to keep up with them. So, from now on those that leave a comment will need to wait for me to approve it before it’s posted. If you’re a spammer, your comment will not be approved. If you’re not a spammer I will approve your comment as soon as possible, likely within 24 hours.

This was bound to happen at some point I guess. My apologies. Blame the spammers.

BSD How To Setup And Configure FreeBSD As A Syslog Server

0 Comments

I’ve grown tired of connecting to each host individually in my network to examine their log files. In addition to logging events locally, I would like these hosts to send their logs to a designated host in my network, resulting in a single location where I can examine and analyze all logs.

This post describes how to setup and configure a machine running FreeBSD to be a system log or “syslog” server, receiving incoming log events from other hosts in the network. A second machine, also running FreeBSD, will be configured to send its log events to the syslog server.

For purposes of example, we’ll use the hostname “server” for the machine hosting our our syslog server, and “client” for the other machine – the one sending its log events to the syslog server. All steps involved assume that FreeBSD is installed and operating correctly on both machines. All commands are issued as the root user.

The versions for the software used in this post were as follows:

  • FreeBSD 10.0-RELEASE
  • Let’s get started…

    Configure the syslog server

    First, we need a file in server’s /var/log directory to host the log events coming from client. For our example, we’ll make this file name the same as client’s hostname. While you don’t need to use the .log extension, I find it helpful as it clearly indicates the purpose of the file:

    touch /var/log/client.log
    

    Next we need to add a couple of options to syslogd, the FreeBSD utility that reads and logs messages to the system console and log files. Open server’s /etc/rc.conf file and add the following line, substituting the IP network and network mask for your own:

    syslogd_flags="-4 -a 192.168.1.0/24 -vv"
    

    The -4 (IPv4) option forces syslogd to listen for IPv4 addresses only.

    The -a (allowed_peer) option specifies which clients are allowed to log to this syslog server. This option can take the form of IP address/mask:service, such as “-a 192.168.10.1/24:*” (the `*’ character permits packets sent from any UDP port), or hostname.domain, such as “-a client.home”, or “-a *.home” (assuming that the hostname can be successfully resolved to the correct IP address in the network). Multiple -a options may be also be specified. In this example, allowed_peer will the form of any host within an entire IP network, in this case 192.168.1.0/24.

    Finally, the -v opton indicates verbose logging. If -v is specified once, the event’s numeric facility and priority will be added to the log. If specified more than once, the names of the event’s facility and priority (e.g., “user.notice”) are also added to the log.

    Now we need to add some lines to server’s /etc/syslog.conf file, the configuration file for syslogd. First, the name of server’s hostname, preceeded by a + character, must be added to top of the file – before any existing syslog options (i.e., right before *.err; …, etc.) – so that those existing options will be applied only to log events generated by locally by server. If we did not add this line then all those options would also be applied to the log events that arrive from client. In other words, any options after a +(some_hostname) in the this file will apply until the next +(some_hostname) is parsed:

    +server
    

    Then add following lines to the bottom of /etc/syslog.conf after the last !* , substituting the .home domain for your own:

    +client.home
    *.*	/var/log/client.log
    

    The first line specifies that remote log events will be arriving from client. client can be specified using either its hostname or its IP address. Note that when using a hostname the domain name must be appended to it. In either case, the hostname.domain or host ip address is preceded by a + character.

    The second line contains parameters to control the handling of incoming log events from client, specifically a selector field followed by an action field. The syntax of the selector field is facility.level. The facility portion describes which subsystem generated the message, such as the kernel or a daemon, while the level portion describes the severity of the event that occurred. Multiple selector fields can be used for the same action and should be separated using a semicolon (;). In our example we’ll use the * characters in the selector field to match any log events received by client.

    The action field denotes where to send the log message. In our case, log events will be sent to the log file we created previously. Note that spaces are valid field separators in FreeBSD’s /etc/syslog.conf file. However, other nix-like systems still insist on using tabs as field separators. If you are sharing this file between systems, you may want to use only tabs as field separators.

    Managing the log files

    The file /var/log/client.log will grow over time, making it difficult to locate useful event information as well as taking up disk space. FreeBSD mitigates this problem using using newsyslog, a built-in utility that, among other things, periodically rotates and compresses log files. newsyslog is scheduled to run periodically by the system crontab (/etc/crontab). In its default configuration, it runs every hour.

    newsyslog reads from its configuration file, /etc/newsyslog.conf in order to determine which actions to take. This file contains one line for each log file that newsyslog manages. Each line is comprised of various fields which control the log file’s owner and group, permissions, and when the log file should be rotated. In addition there are several optional fields for controlling log file compression and programs that should be signaled when the log file is rotated. Each field is separated with whitespace.

    In order to have newsyslog recognize client’s log file, we’ll place the following line at the botton of /etc/newsyslog.conf:

    /var/log/client.log		640		5	100		*	JC
    

    In this example, the file permission for /var/log/client.log is set to 640. newsyslog will retain up to five archive files, and rotate the file when its size reaches 100 kB. The * character in the when column instructs newsyslog to ignore a time interval, a specific time, or both and instead only consider the size of the file when determining whether or not to rotate the file. The J flag tells newsyslog compress the rotated log file using bzip2, and the C flag tells newsyslog to create the log file if it does not already exist.

    Finally, let’s restart syslogd and newsyslog on server:

    service -v syslogd restart
    service -v newsyslog restart
    

    Configure the client

    Let’s move on now and configure client so that it will send its event logs to server. Open client’s /etc/syslog.conf file and add the following line after the last !*, to instruct client to send log events of any facility and level to server:

    *.*   @server
    

    server can be specified using either its hostname, hostname.domain or its IP address, preceded by a @ character.

    Now let’s restart syslogd on client:

    service -v syslogd restart
    

    Finally, let’s make sure client is sending its log events to server using the logger utility. Logon to client and issue the follow command:

    logger This message is from client
    

    Now login to server and and check client’s log file:

    tail /var/log/client.log
    

    You should see the message you sent using the logger utility:

    Aug  2 12:54:14 <user.notice> test.home iceflatline: This a test message from client
    

    Conclusion

    That’s it. In addition to logging events locally, the client host will send its logs to our syslog server, resulting in a single location where log events can be examined and analyzed.

    References

    NEWSYSLOG(8)
    NEWSYSLOG.CONF(5)
    SYSLOGD(8)
    SYSLOG.CONF(5)

    Tags: , ,

    Networking How To Assign Static IP Addresses to OpenVPN Clients In pfSense

    0 Comments

    This post describes how to configure the OpenVPN server in pfSense to assign static IP addresses to its remote access client hosts.

    pfSense (i.e., “making sense of packet filtering”) is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, and can be managed entirely from a web-based or command line interface. In addition to being a firewall and routing platform, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

    OpenVPN is a lightweight VPN software application supporting both remote access and site-to-site VPN configurations. It uses SSL/TLS security for encryption and is capable of traversing network address translation devices and firewalls. The OpenVPN community edition is free, open source software and portable to most major operating systems, including Linux, Windows 2000/XP/Vista/7, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris. It is distributed under the GPL license version 2.

    All steps involved assume that pfSense and its OpenVPN server are installed and operating correctly. The versions for the software used in this post were as follows:

  • pfSense v2.1
  • Let’s get started…

    Connect to your pfSense firewall using SSH and open /var/etc/openvpn/server1.conf. Ensure that this configuration file contains the following line pointing to a valid directory for containing OpenVPN client host configuration files. The default directory in pfSense for this purpose is /var/etc/openvpn-csc. You can change this directory if you wish but for our example we’ll retain the default:

    	
    client-config-dir /var/etc/openvpn-csc
    

    In this directory we will create a file for each remote access client host we want the OpenVPN server to assign a static IP address to. The file name of each file must be the same name as the client host’s OpenVPN SSL certificate. For example, if you would like to configure a static IP for a client host with the certificate name “bob” then create the following file:

    cd /var/etc/openvpn-csc	
    touch /var/etc/openvpn-csc/bob
    

    Open this newly created file and add the following line, which contains a pair of IP addresses from the IPv4 virtual network you’ve configured for private communications between the OpenVPN server and your client hosts. Note that you cannot use just any pair of addresses from within this subnet. Each pair of ifconfig-push addresses represent the OpenVPN client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows client hosts and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from set defined in the “Configuring client-specific rules and access policies” section of the OpenVPN HOWTO. In this example, our OpenVPN server is using the virtual network 192.168.20.0/24 and we’ve chosen an appropriate pair of endpoint addresses to use from this subnet. Note that the first IP address in following line is the IP address assigned to the client host, the second is the address the server uses:

    ifconfig-push 192.168.20.6 192.168.20.5
    

    Once you’ve added this line to /var/etc/openvpn-csc/bob you’ll need to restart the OpenVPN server in pfSense. You can do this from Status->Services in the pfSense “webConfigurator” interface.

    There you have it. Some minor configuration of your pfSense machine and its OpenVPN server will start assigning static IP addresses to the remote access client hosts you designate.

    References

    http://openvpn.net/index.php/open-source/documentation/howto.html

    Tags: , ,

    BSD How To Create, Configure And Connect To A FreeBSD Instance In Amazon EC2

    0 Comments

    FreeBSD is an free and open source advanced computer operating system used to power modern servers, desktops and embedded platforms.

    Amazon Elastic Compute Cloud (“EC2″) provides resizable computing capacity in the Amazon Web Services (“AWS”) cloud. Amazon EC2 can be used to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. An Amazon Machine Image (AMI) is a template that contains a software configuration (for example, an operating system, an application server, and applications). From an AMI, you launch an instance, virtual servers that can run applications. They have varying combinations of CPU, memory, storage, and networking capacity, and give you the flexibility to choose the appropriate mix of resources for your applications.

    This post describes how to create and configure a FreeBSD instance in Amazon EC2. Then goes on to explain how to connect to the new instance using SSH from a machine running a BSD, Linux or Windows operating system.

    The steps discussed in this post assume you have an active AWS account. If you do not, you can sign up for one at Amazon Web Services.

    Let’s get started…

    Create and Configure the FreeBSD Instance

    Fire up your web browser and navigate to Amazon Web Services. Login to the AWS Management Console by selecting “AWS Managment Console” from among the options in the drop down list under “My Account/console” (See Figure 1).

    Screenshot showing how to find the Amazon AWS Management Console

    Figure 1

    Once you’ve successfully logged in, select “EC2 Virtual Servers in the Cloud” from among the options listed under the “Compute & Networking” section (See Figure 2).

    Screenshot showing the Amazon AWS Management Console

    Figure 2

    Next you’ll choose the Amazon EC2 “region” under which the FreeBSD instance will be created. In this example we’ll select the Oregon region (See Figure 3).

    Screenshot showing the selection of an Amazon region where the FreeBSD instance will be created

    Figure 3

    Now select “Instances” from among the options under the “Instances” category on the left side of the page. If this is the first time you’ve created an instance in this Amazon EC2 region you’ll be greeted with a message indicating “you do not have any running instances in this region” and a button to launch one (See Figure 4).

    Screenshot showing the Amazon AWS EC2 launch instance screen

    Figure 4

    Select “Launch Instance” and you’ll be greeted with Amazon’s quick start guide for creating a new AMI. Select “Community AMIs” from among the choices on the left side of the web page where you will be offered the ability to search for and select an AMI from the AWS user community. Great, but what do we search for? Fortunately Colin Percival, FreeBSD developer, member of the FreeBSD Core team, and the FreeBSD Security Officer, has created a number of FreeBSD AMIs and has graciously provided a handy matrix listing those AMIs as well as their associated numbers. At the time of this post, the FreeBSD 9.2-RELEASE for 64-bit Windows AMI will be the most appropriate one to use for most users and applications and this will be the one we’ll use in our example. Make a note of the AMI number corresponding to the Oregon region and enter that number in the search box. Amazon will search for this AMI and return the correct result (See Figure 5).

    Screenshot showing the successful search results for an FreeBSD AMI

    Figure 5

    Next, select “Select” where you’ll be asked to choose an instance type. Amazon EC2 provides several instance types optimized to fit different use cases. In our example we’ll use a “Micro” instance. a low-cost (often free) instance type, providing a small amount of CPU and memory resources. Micro instances are suited for lower throughput applications, including low traffic websites or blogs, and small administrative applications (See Figure 6).

    Screenshot showing the selection of a Amazon EC2 Micro instance

    Figure 6

    After choosing an EC2 instance that best meets your requirements, select “Next: Configure Instance Details” where you will be presented with a list of default options that can be modified, if desired, to better suite your needs. Hovering your mouse over the “i” icon near an option will describe its purpose in greater detail. One option that may prove helpful is the termination protection. Enabling this will prevent the instance from being accidentally “terminated” (i.e., deleted). Once enabled, you will not be able to delete the instance through the AWS Management Console until this option is once again disabled. For our example, however, we’ll simply retain the default options (See Figure 7).

    Screenshot showing the configuration of the default Amazon EC2 instance options

    Figure 7

    Now select “Next: Add Storage” where you can adjust the size of the default or “root” Elastic Block Store (“EBS”) volume. You can also attach additional EBS volumes to your instance, or edit the settings of the root volume. You can also choose to delete the volume should you decide to terminate the instance. For our example, we’ll retain the 10GB root EBS volume and all default settings (See Figure 8).

    Screenshot showing the Amazon EC2 EBS storage volume configuration options

    Figure 8

    After configuring storage, select “Next Tag Instance” where you be given the option of creating a “Tag” for your instance (See Figure 9). Tags enable you to categorize your AWS resources in different ways, for example, by purpose, owner, or environment. Each tag consists of a key and a value, both of which you can define. Uniquely tagging instances can be beneficial, particularly if you plan on creating many of them. Again, this is an optional step, and since we’re creating a single instance, we’ll forgo tagging for the moment and move on to the next step: create configure the security group.

    Screenshot showing the Amazon EC2 instance tagging option

    Figure 9

    A security group is a set of firewall rules that control the traffic for your instance. For example, if you want to set up a web server and allow traffic to reach your instance, you would add rules that permit unrestricted access to HTTP and HTTPS ports.

    You can create a new security group or select from an existing one. In our example we’ll create a new security group. Ensure that “Create a new security group” is selected, then choose a name. Other than the total number of characters (maximum of 255), there are no restrictions. You can also add a description for the security group if desired.

    With the exception of Remote Desktop Protocol (TCP port 3389), there are no incoming ports open for a new instance by default (Amazon EC2 instances requires port 3389 to be open to permit access to the instance via the web). For our example, we’d like to connect to the new FreeBSD instance using SSH so we’ll need to create a new rule allowing incoming port 22 connections. Select “Add Rule”, then select “SSH” from among the options in the drop down list under “Protocol”. TCP and port 22 will be automatically assigned to this selection. If you would like to use a TCP port other than 22 for SSH connections, you should select “Custom TCP Rule” instead and enter the desired port number under “Port Range (Code)”.

    Next, determine if and how you’ll filter incoming SSH connections to your FreeBSD instance. If you’d like to connect from any network, then select “Anywhere” from among the options in the drop down list under “Source”, else you can limit incoming connections to the IP your currently using or to a custom IP address or IP subnet. For our example, we’ll allow incoming SSH connections on port 22 from anywhere (See Figure 10). Repeat these steps to create additional rules to meet your requirements.

    Screenshot showing the configuration of Security Group rules in Amazon EC2

    Figure 10

    When complete, select “Review and Launch”, where you’ll be given one last opportunity to modify your settings. When complete, select “Launch” where a pop up screen will provide the opportunity to select an existing key pair or create a new key pair. A key pair consists of a OpenSSL public key, which Amazon AWS retains and copies to your instance, and a private key that you download and retain. Together, they allow you to connect to your FreeBSD instance securely. If this this is first time you’ve created an instance you’ll likely not have an existing key pair from which to chose. If this is the case, select “Create a new key pair” from among the options in the drop down list and enter a name for your new key pair. In our example we’ll use the name “ec2-or-freebsd.” Now select “Download Key Pair” and save the file in a secure and accessible location (See Figure 11).

    Screenshot showing the creation of a new key pair in Amazon EC2

    Figure 11

    Next, select “Launch Instances”, followed by “View Instances” and you’ll be taken to a page showing your FreeBSD instance launching. After a minute or two, the “Instance State”
    will change from “pending” to “running” (See Figure 12). You can stop your instance by selecting “Stop” from among the options in the drop down list under “Actions” located at the top of the page.

    Screenshot showing a running FreeBSD instance in Amazon EC2

    Figure 12

    Finally, let’s get the host name of our FreeBSD instance. Select “Connect” at the top of the instance page. The host name is contained next to the field “Public DNS”. In this example the host name is: ec2-user@ec2-54-203-111-192.us-west-2.compute.amazonaws.com. (See Figure 13) As you can see, these host names are typically very long. Instead of trying to memorize it, write it down, or simply highlight it and copy it to file you can access later. Note: if you stop your instance a new host name will be assigned to it when it’s restarted. Consequently, you’ll have to repeat these steps.

    Screenshot showing the FreeBSD instance host name being copied from Amazon EC2

    Figure 13

    Connect to the instance from Windows

    Now that we have our new FreeBSD instance up and running under Amazon EC2 let’s turn our attention to connecting to it using SSH under Windows. Since Windows doesn’t support SSH natively, we’ll need an SSH client. There are many out there to choose from, but the one I typically use is PuTTY, a free implementation of Telnet and SSH for Windows and Linux/BSD platforms.

    PuTTY does not natively support the private key format *.pem generated by Amazon EC2, so we’ll also need a way to convert this key file to a key format that the PuTTY application can use. For this we’ll use PuTTYgen, a free RSA and DSA key generation utility, which can convert keys to *.ppk, the file format required by PuTTY. You can download standalone versions of PuTTY and PuTTYgen, or simply download the Windows installer version of PuTTY, which will also install PuTTYgen, as well as Pageant, an SSH authentication agent for PuTTY.

    Fire up PuTTYgen and select “Load”. Navigate to where you downloaded the ec2-or-freebsd.pem file and select “Open” (Note: you may have to change the search filter from “PuTTY Private Key Files (*.PPK)” to “All Files (*.*)” in order to readily locate the file). Once ec2-or-freebsd.pem has been successfully loaded into PuTTYgen, you can modify the “Key comment” field if desired, as well as add a passphrase to protect your private key. While optional, I strongly suggest you add a passphrase. Electing not to means that anyone gaining access to your private key will also quite easily be able to access your FreeBSD instance (See Figure 14). Once complete select “Save private key” and select a name (for our example, we’ll use the same name: ec2-or-freebsd) and a location to save the new key file.

    Screenshot showing the creation of a ppk file in PuTTYgen

    Figure 14

    Exit out of PuTTYgen and fire up PuTTY. Navigate to Connection->SSH->Auth. Under Authentication parameters select the Browse button and select the ec2-or-freebsd.ppk file you saved in the previous step. Navigate back up to Session and copy and paste the host name for your FreeBSD instance in the “Host Name (or IP address)” field. You’ll connect as “ec2-user” so prepend this user name to the host name so that the entire field looks like this: “ec2-user@ec2-54-203-111-192.us-west-2.compute.amazonaws.com”. If you chose a different SSH port number other than the default 22 when setting up your instance’s security group, ensure that number is reflected in the “Port” field.

    Now select “Open” and the PuTTY client will connect to your FreeBSD instance. If this is the first time you’ve connected to it, you’ll receive a warning concerning the authenticity of the host you’re trying to reach. If you’re sure this is the correct instance and you want to continue connecting, select “Yes” to add the key to PuTTY’s cache and carry on connecting. If you want to carry on connecting just once, without adding the key to the cache, select “No”. You’ll be asked to provide the passphrase (if you created one) for your private key and you’ll be connected to the instance. You can now use your FreeBSD instance like any other FreeBSD system, with the exception that on versions prior to 10.0-BETA1 you can’t use FreeBSD Update to fetch kernel security updates.

    Connect from BSD or Linux

    Connecting to your FreeBSD EC2 instance via SSH is significantly easier in Linux or BSD. Start by checking to see if the .ssh directory exists in your home directory. If it does not, create it and set it’s permissions appropriately:

    mkdir ~/.ssh
    chmod 700 ~/.ssh
    

    Now move the ec2-or-freebsd.pem file you downloaded to ~/.ssh and modify its permissions appropriately:

    chmod 600 ~/.ssh/<your-pem-file>
    

    As an optional step you can add a passphrase to your key. I strongly suggest you do, else anyone gaining access to your key will also quite easily be able to access your FreeBSD instance:

    openssl rsa -in ec2-or-freebsd.pem -des3 -out ec2-or-freebsd.pem
    

    Now let’s connect to our FreeBSD instance:

    ssh -i ~/.ssh/ec2-or-freebsd.pem  ec2-user@ec2-54-203-111-192.us-west-2.compute.amazonaws.com
    

    If you chose a different port number than the default when setting up the instance’s security group, then you’ll need to specify that on the command line as well:

    ssh -p <your-port-number> -i ~/.ssh/ec2-or-freebsd.pem  ec2-user@ec2-54-203-111-192.us-west-2.compute.amazonaws.com
    

    If this is the first time you’ve connected to it, you’ll receive a warning concerning the authenticity of the host you’re trying to reach. If you’re sure this is the correct instance and you want to continue connecting type “yes” at the prompt. The public key of your FreeBSD EC2 instance will be added to ~/.ssh/known_hosts and you will be connected.

    Conclusion

    Well, that’s it. Thanks to some fine work by Colin Percival, you can easily create, configure and connect to your own FreeBSD instance in Amazon EC2. Now that you know that your *.ppk and/or *.pem private key works, you should back it up to offline media such as a flash drive or CD and keep it someplace secure.

    Issues to note

    Amazon does not provide a easy way to verify the key fingerprint – the one listed in the EC2 Management Console. I did manage to find this rather obscure command that will work from Linux/BSD, but I have yet to find an easy way to perform this task under Windows, outside of installing and setting up the the Amazon EC2 command line interface tools.

    openssl pkcs8 -in ec2-or-freebsd.pem -nocrypt -topk8 -outform DER | openssl sha1 -c
    

    References

    http://aws.amazon.com/documentation/ec2/

    Tags: ,

    Networking How To Create And Configure VLANs In pfSense

    14 Comments

    pfSense is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, managed entirely from a web browser or command line interface. pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

    A VLAN (“Virtual Local Area Network”) is a logical grouping of network hosts (and other resources) connected to administratively defined ports on a switch. This enables hosts to communicate as if the attached to the same physical medium, when in fact they may actually be located on different LAN segments. A VLAN is treated like its own subnet or broadcast domain, which means that Ethernet frames broadcast onto the network are only switched between the ports logically grouped within the same VLAN.

    In this post I will describe how to create and configure VLANs in pfSense. Once configured, you’ll be able to route (or prevent routing) traffic between each VLAN, and each VLAN will be able to share the same Internet connection. To help explain the steps involved, we’ll create two static VLANs on a 24-port switch and trunk those VLANs from the switch to the LAN interface on pfSense, where we will assign each VLAN a unique /24 private IPv4 subnet.

    All steps involved assume that: 1) pfSense is installed correctly and providing basic Internet connectivity to an existing LAN interface; 2) the NIC (“Network Interface Controller”) assigned to the LAN interface supports IEEE 802.1Q VLAN tagging; and, 3) the switch connected to the LAN interface is capable of supporting the creation, configuration and trunking of port-based VLANs.

    The software versions used in this post were as follows:

  • pfSense v2.1 (x64)
  • The switch used in this post was a Cisco model SG200-26; a so-called “smart switch,” featuring, among other things, Gigabit Ethernet, a web-based management interface, and simultaneous support for up to 256 port-based and IEEE 802.1Q tag-based VLANs.

    Each switch, and its associated management interface, however, is different; therefore, you’ll need to make the appropriate adjustments when following the instructions in this post in order to successfully configure your particular switch.

    Let’s get started…

    Configuring The Switch

    As you may recall, static VLANs, often referred to as “port-based” VLANs, are created by assigning switch ports to a preconfigured VLAN identifier. In our example, we’ll configure two static VLANs on our switch and assign them VLAN ID 10 and VLAN ID 20. Note that you can use any positive integer between 2 and 4094 you’d like for your VLAN ID, however, VLAN IDs 1 and 4095 should be avoided because, as a general rule, most switches by default assign all ports to VLAN ID 1, the “administrative” VLAN ID, and VLAN ID 4095 as the “discard” VLAN.

    Begin by navigating to VLAN Management->Create VLAN and select “Add.” Enter a value of 10 in the “VLAN ID” field and enter a name to denote this particular VLAN in the “VLAN Name” field. In this example, we’ve used the name “vlan10.” When complete, select “Apply”. (See Figure 1)

    Screenshot showing the creation of a new VLAN ID 10 in the Cisco SG200-26 switch

    Figure 1

    Perform the same steps to create the second VLAN, this time assigning a value of 20 to the “VLAN ID” field and “vlan20″ to the “VLAN Name” field. When complete, select “Apply” and you should see the newly minted VLANs listed (See Figure 2).

    Screenshot showing that two VLANs have been created in the Cisco SG200-26 switch

    Figure 2

    Before assigning membership of a particular port to one of our new VLANs, we must first configure that port to be either an “Access” port or a “Trunk” port. Access ports are ports that are members of only one VLAN. This type of port is normally used for attaching end devices which are generally unaware of a VLAN membership, either because their NIC is incapable of tagging Ethernet frames a VLAN ID, or they are not configured to do so. Switch ports configured as Access ports remove any VLAN information from the Ethernet frame before it is sent to the device. Trunk ports on the other hand can carry multiple VLAN traffic, and are normally used to connect switches to other switches or to routers. It is very often the case that small-business grade switches, such as the Cisco SG200, designate each port as a Trunk port by default.

    To keep our example simple, we’ll assume that the device(s) connected to the switch are not configured, or are unable to be configured, to tag Ethernet frames with a VLAN ID. Consequently, we’ll configure ports 1 and 2 as Access ports, and assign each membership in one of the two newly created VLANs. Furthermore, we’ll also assume that port 25 is currently being used to connect the switch to the pfSense LAN interface, and configure it as a Trunk port, assigning it membership in both of the newly created VLANs.

    Navigate to VLAN Management->Interference Settings, select port 1 and then select “Edit”. Change the Interface VLAN Mode from Trunk to Access, then select “Apply” (See Figure 3). Now follow similar steps to configure port 2 as an Access port.

    Screenshot showing port 1 being configured as an Access port in the Cisco SG200-26 switch

    Figure 3

    Next, navigate to VLAN Management->Port VLAN Membership, select port 1 and then select “Join VLAN”. Since Access ports can be added as untagged to only a single VLAN, we’ll need to first remove the default VLAN the switch automatically assigns to each port (usually VLAN 1). Highlight VLAN 1 by left-clicking on it, then select the arrow icon to remove it from the interface. Now highlight VLAN 10 by left-clicking on it, then select the arrow icon to add it to the interface, ensuring that “Untagged” is selected from among the options under “Tagging”. Select “Apply” when completed (See Figure 4). Now follow similar steps to join port 2 to VLAN 20.

    Screenshot showing port 1 being joined to VLAN 10 in the Cisco SG200-26 switch

    Figure 4

    With switch ports 1 and 2 configured as Access ports and joined to VLANs 10 and 20 respectively, any Ethernet frames that enter those ports will be tagged with the appropriate VLAN ID. Now let’s configure the port 25, the port that is connected to the LAN NIC in pfSense. This port will be configured as a Trunk port and joined to both VLAN 10 and 20 so that, in addition to passing the Ethernet frames from from devices attached to the other ports on the switch to pfSense, it will also pass Ethernet frames tagged with VLAN IDs 10 and 20 (from ports 1 and 2).

    Ensure that port 25 is configure as a Trunk port, then navigate to VLAN Management->Port VLAN Membership, select port 25 and then select “Join VLAN”. Highlight VLAN 10 by left-clicking on it, then select the arrow icon to add it to the interface, ensuring that “Tagged” is selected from among the options under “Tagging”. Follow similar steps to join port 25 to VLAN 20, then select “Apply” when completed (See Figure 5).

    Screenshot showing port 25 being joined to VLAN 10 and VLAN 20 in the Cisco SG200-26 switch

    Figure 5

    That’s it for configuring the switch. If your switch supports both a running configuration and a startup configuration, make sure to save the changes you’ve made to the startup configuration so that they are not lost should the switch reboot for any reason.

    Configuring pfSense

    Now we need to create and configure VLANs 10 and 20 in pfSense. Navigate to Interfaces->assign and make note of the device driver name assigned to the LAN NIC. For our example we’ll assume the device name is “em2″ (See Figure 6). The LAN interface will serve as the “parent interface” for the VLAN interfaces we will create in the next step.

    Screenshot showing the device driver name assigned to the LAN NIC in pfSense

    Figure 6

    Next, navigate to Interfaces->assign->VLANs and select the “+” icon. In the subsequent screen, select “em2″, the LAN NIC interface, from among the options in the drop down list under “Parent interface”, and enter the value of 10 under “VLAN tag”. Add an optional description for this VLAN under “Description”, then select “Save” (See Figure 7). Follow similar steps to create the VLAN 20 interface.

    Screenshot showing the creation of a VLAN interface in pfSense

    Figure 7

    After creating the VLAN interfaces, return to Interfaces->assign and select the “+” icon to add an interface. Select “VLAN 10 on em2 (vlan10)” from among the options in the drop down list, then select “Save” (See Figure 8). Follow similar steps to add the VLAN 20 interface. At this point you’ll notice that under the “Interface” column pfSense has denoted VLAN 10 and VLAN 20 as “OPT1″ and OPT2″ respectively. Don’t worry, we’ll address that next.

    Screenshot showing the creation of a VLAN interface in pfSense

    Figure 8

    Navigate to Interfaces->OPT1 and select “Enable Interface”. Under “Description” replace “OPT1″ with “VLAN 10″, then select “Static IPv4″ from among the options in the drop down list under “IPv4 Configuration Type”. For our example, we’ll use network 192.168.10.0/24 for VLAN 10 by assigning the static IP address 192.168.10.1 on this interface, and selecting the network mask of “24” from among the options in the drop list under the “Static IPv4 configuration” section. The other parameters can remain at their default values. Select “Save” and “Apply changes” when complete (See Figure 9). Follow similar steps to enable the OPT2 interface, assigning it the name “VLAN 20″ with a static IP address of 192.168.20.1 and a network mask of 24. Now if you navigating back to Interfaces->assign you will see VLAN 10 and VLAN 20 listed and labeled with the description you added when enabling the interface in the previous steps.

    Screenshot showing the VLAN 10 interface being enabled and configured in pfSense

    Figure 9

    Next, we need to build a firewall rule for our two new VLANs so that traffic can pass to / from the WAN interface, and by extension, to the Internet. Navigate to Firewall->Rules and select the tab for VLAN 10. Select the “+” icon to create a new rule. For our example, we’ll build a simple outbound pass rule for any protocol in VLAN 10, similar to the way a typical LAN outbound pass rule would be configured. Select “any” from among the options in the drop down list Under “Protocol”, and under “Source” select “VLAN 10 subnet” from among the options in the drop list under the “Type” field. If desired, you may enter a description of this newly created rule for your reference under “Description”. The other parameters can remain at their default values. Select “Save” and “Apply changes” when complete (See Figure 10). Now select the tab for VLAN 20 and follow similar steps to create its firewall rule.

    Screenshot showing the creation of a firewall rule for VLAN 10 in pfSense

    Figure 10

    Unless you plan to assign static IP addresses to host devices, you’ll want to configure a DHCP server for each of the new VLANs. Navigate to Services->DHCP server and select the tab for VLAN10. Select “Enable DHCP server on VLAN10 interface”, then enter the range of IP addresses within the network 192.168.10.0/24 you’d like the DHCP server to use under “Range”. Finally, enter an IP address for the network gateway under “Gateway”. Unless your requirements call for something different, you would typically use the IP address assigned to this interface as the gateway address. For our example this address will be 192.168.10.1. The other parameters can remain at their default values. Select “Save” when complete (See Figure 11). Follow similar steps to configure the DHCP server for VLAN 20, this time entering a range of IP addresses within the network 192.168.10.0/24, and 192.168.20.1 as the IP address for the network gateway.

    Screenshot showing the creation and configuration of a DHCP server for VLAN 10 in pfSense

    Figure 11

    Wrapping up

    At this point the LAN switch and pfSense should be configured to support VLAN 10 and VLAN 20. To test, connect a host device such as a desktop or laptop computer to port 1 on the switch. If you’ve configured everything as described, you should receive an IP address within the DHCP address range you’ve specified for VLAN 10 network 192.168.10.0/24. The default gateway, DHCP server and DNS server addresses should be 192.168.10.1. You should also have Internet connectivity. Connecting this same device to port 2 of the switch should yield the same status: you should receive an IP address within the DHCP address range you’ve specified for VLAN 20 network 192.168.20.0/24; the default gateway, DHCP server and DNS server addresses should all have address 192.168.20.1; and once again you should have Internet access.

    Be aware that as currently configured, each VLAN is routed to all other VLANs. If you would like to disallow some or all traffic to/from a particular VLAN you must create firewall rules explicitly stating what traffic should not be routed. Keep in mind that pfSense evaluates firewall rules on a first-match basis (i.e. the action of the first rule to match a packet will be executed). So, for example, if you wanted to block all VLAN 10 traffic from reaching VLAN 20 you might create a rule to that effect and move it before the one we created previously to route all VLAN 10 traffic to any destination (See Figure 12).

    Screenshot showing the placement of a firewall rule blocking all VLAN 10 to VLAN 20 traffic in pfSense

    Figure 12

    Conclusion

    VLAN support in pfSense is not hard to configure nor complicated to manage, assuming your switch and NICs support this capability. To help explain the steps involved, we created two static VLANs on a commodity 24-port small-business switch and trunked those VLANs to the LAN interface on pfSense. We then created and added the VLAN interfaces, created the requisite firewall rules, and assigned each VLAN a unique /24 private IPv4 subnet with host addressing handled using DHCP. Each VLAN is able to share the pfSense’s Internet connection and we are able further configure pfSense to prevent routing traffic between each VLAN, if desired.

    Tags: , ,