Sunday, August 28, 2016

Re-Purposing VisionNet M505N Modems as Wireless Access Points, Part Five: IP Filtering

For this entry, it is specifically 'Outgoing IP Filtering' under the 'Security' menu item, and only for isolating your "Internet of Things" network further. It is also under the assumption that you have determined where your IoT device(s) "phone home" on the Internet like I have. There is some preliminary work we are going to do on pfSense first, then we will return to the modem for the IP filtering settings.

Remember that the default behavior of your IoT Wireless Access Point is to not filter any outbound traffic. It will be easiest to limit all but a few specific ports from within pfSense. Log-in, and navigate to the 'Firewall' menu, then to 'Aliases'. Create the appropriate aliases under the 'IP' section for the IP addresses of your IoT WAP (and guest WAP if necessary) and entries of where your IoT "phone home".


Next, create the rule(s) for the traffic that is coming from the "Internet of Things" Wireless Access Point to your DMZ interface of the firewall. Here I am only allowing HTTPS (TCP port 443) to come from my "IoT_IP" "WAN" address when it authenticates to the DMZ interface, and that traffic is only allowed to go to the "Honeywell" addresses in the "Honeywell" alias. Save your changes.






On the modem, under the 'Security' menu item we will select 'Outgoing IP Filtering'. You would have a range of 'Source IP address(scope)' that includes all of the other possible LAN IP addresses with the exception of your IoT device. In this example, my Honeywell thermostat would be on a reserved address of 192.168.100.6 (which is the last usable address of that subnet). We are limiting only the IoT device to be a source of HTTPS requests (other possible devices on IP addresses of that LAN would have that port blocked).


We had also used the ability to filter our wireless by MAC address, but there is even a way to limit a DHCP address from being assigned to a system wired to the modem unless it is plugged into a particular port. In this scenario, you are occasionally maintaining the IoT WAP, and plugging into a specific port with your system set to obtain an IP address automatically (via DHCP). You do want security (you could turn off DHCP for all of the wired ports if the IoT WAP was in an unsecured area, and require yourself to set an obscure IP address in order to access the WAP), but don't make things overly hard for yourself.

This is under the primary 'LAN' settings, then click on the 'DHCP Advance Setup' button. Notice that the "eth3" entry is removed since we are using it for our "WAN" connection. "wl0" is for the wireless network, and the entries below it are the optional "guest" wireless networks that should never be enabled. I will only receive an IP address from the modem if I plug into the first Ethernet port.


Hopefully this series has been helpful in setting up an isolated IoT network. I like the VisionNet M505N modems for re-purposing them as Wireless Access Points because they have so many useful features to their configuration. Please stay tuned as we continue with other topics.

Monday, August 22, 2016

Re-Purposing VisionNet M505N Modems as Wireless Access Points, Part Five: URL Filtering

The concepts of isolating your "Internet of Things" device(s) is quite simple:  Provide that IoT with the connection it needs and nothing more, nothing else is allowed to connect to it, and that it doesn't connect to anything other than what it needs. After I set up my IoT Wireless Access Point (for only one device, my Honeywell thermostat) I connected to a managed Ethernet switch in line to the DMZ interface of my pfSense firewall, mirrored the port that was receiving packets from that WAP, and started "Wireshark" (software that can examine data on the connection).

After just a few minutes there was traffic to two adjacent IP addresses on port 443 (HTTPS. IoT will commonly use a port that would not be blocked for an Internet connection). Tracing the IP addresses, yielded that they were a part of "AlarmNet.com", run by Honeywell. I have them shown here as 'Allowed' addresses on the modem's 'URL Filter' (under the 'Security' menu item):


If it were only that easy: Allow my thermostat to connect only to those IP addresses to "phone home" on that port, and nothing else. Therein lies the rub. The default actions of a firewall (including pfSense) when it is first installed is to block everything incoming from the Internet and to allow all traffic outbound.  I can show areas that I will try to block everything but what is shown above, but it will be complex. Remember that my "guest" wireless (as well as other potential systems later) is also on my DMZ network.

The IoT WAP does use that PPPoE authentication method shown in Part One to get a specific IP address on my pfSense firewall that can be better filtered there, but I also want to have entries on the modem itself to offload that work as much as possible. For the moment I also want to describe  how 'URL Filtering' will be used for your guest wireless. Of course, it will be in contrast to the method shown above, with specific URL addresses 'Blocked' instead of allowed.

We're back to an entry I had back in April on guest wireless security, including many of the same steps I have done in this multi-part series. It's not through yet, but there will likely be additional entries on IP addressing, MAC addresses, and ports. I'm not going to provide a list of URLs you should block for your guest network (URL filtering, and the next 'Outbound IP Filtering' also is for the wired LAN ports of the modem in addition to the wireless), but you can probably think of a few yourself. Stay tuned, there is more to come!

Sunday, August 21, 2016

Re-Purposing VisionNet M505N Modems as Wireless Access Points, Part Four: Access Control Settings

We're ready to put some real security on the VisionNet M505N modems we have re-purposed into a WAP for both isolating our IoT  devices and a guest wireless network. Just like before, later settings will differ based on how you are using the modem (whether for IoT isolation or guest wireless). I'll start with the basic settings for both, and include an extremely helpful 'hidden' page you can use to your benefit.

In fact, since you now have a functional configuration that hasn't been set up for restricting your own access, we are going to cover that 'hidden' page. While still connected to the modem, navigate to the address "http://[modem IP address]/customermain.html". Click on the 'Backup Current Settings' button. It reports when it is finished (it is only a matter of seconds).


You've just written the current configuration of the modem to be the default (down to the username, password, and wireless settings). To revert to this state (if you would mess up the configuration, and lock yourself out of the modem) just hold the reset button in for five seconds, and release. Otherwise, you have to do a 90-second reset to revert back to the true factory settings (and losing all of your configuration).

Of course, that sets the modem to default management accounts. To change the passwords for those accounts, click on the 'Management' menu item, then select 'Management Accounts'. The page describes the accounts very well, typically the default password for the "admin" account is "0123456789", and the password for the "support" account is also "support". The "support" account works from the "WAN-side" whereas the "admin" account is for the modem's LAN.


Next is the "Access Control List". From the same 'Management' menu item, and select 'IP Restriction'. Generally I first 'Add' the range of IP address(es) I am currently on to the modem, then 'Enable Access Control Mode'. Keep in mind that you can set the M505N externally (using the "support" account) by setting the appropriate IP address range(s).



You need to turn on which management services (like HTTP or SSH) in 'Access Control' from the same 'Management' menu item. If the "ppp0" column doesn't show, click on the drop-down box at the top of the chart. It shows which modem interface services are accessible from the LAN (even to turn them off if you only manage the WAP externally) and "WAN" (the DMZ interface of your pfSense firewall). Remember you can fast-reset the modem if you mistakenly cut off your own access.


'Apply/Save' any changes you make, and remember if you have a working configuration you want to save as a default, access the 'hidden' page. In the next part I will start to cover the IP and URL filtering you can use, stay tuned!

Saturday, August 20, 2016

Re-Purposing VisionNet M505N Modems as Wireless Access Points, Part Three: Wireless Settings

We're still plugged into one of the LAN ports (Ethernet '1', '2', or '3') of the network we have set up on the VisionNet M505N modem we are re-purposing for isolated "Internet of Things" connections and "guest" wireless for visitors we aren't going to give access to our regular networks. The modem is happily purring away having authenticated to the DMZ interface of your pfSense firewall that we did in the first section of this multi-part series. Now it is time to configure the wireless settings of the modem, diverging whether it is for IoT isolation or a guest network.

Almost all of the time both types of networks will be designed as limited wireless connections, but your "guest" network may have the need to also have a few wired ports. My initial descriptions will be for an isolated IoT connection, although I will provide the data alongside for setting up a "guest" network as well. Select the 'Wireless' menu item on the left.

Of course, we're going to 'Enable Wireless'. You may want to 'Hide Access Point' (not broadcasting the "SSID", the name of the wireless network) only after connecting your IoT device(s) to the wireless - and typically you won't have a "guest wireless network" hidden at all. For both types of wireless networks, you want to enable 'Client Isolation' for obvious reasons. Not quite as clear, you want to check 'Disable WMM Advertise' on your IoT and "guest" networks (but enable WMM Advertise on your main LANs; it means "Wi-Fi Multimedia" functionality and can help improve streaming from the Internet): Provide only basic services to your visitors, and limit the bandwidth of those connections (which will be a later blog post).

Back to IoT isolation, give that (eventually hidden) wireless network: Give it a long (with spaces) or randomized name. The goal is for nothing except for your IoT devices to connect to it. A guest network is, of course, different: Name it for the function, something like "Guest Wireless". For an IoT network, I have set '3' as the 'Max Clients', a guest wireless should be slightly more, but less than the default of "16". Click on 'Apply/Save'.


Now select the sub-item of 'Security Settings'. In reality (and contrary to the notion that a password is all that is needed for security), we will only set a password on the isolated IoT scenario, unless you want to have a basic password you change occasionally for your guests. "WPS", the method with a button on the modem to easily establish a wireless link should be 'Disabled' with IoT, but possibly enabled for your guest network. Use a WPA2 "Pre-Shared Key" for IoT, and if you are choosing to have a password for your guest network. Click on 'Apply/Save' when finished.


Here is where we gain real security: Click on the 'MAC Filtering' sub-item. I will show an easy way to determine the MAC address(es) connected to your VisionNet M505N modem in a moment, so you might need to return to this area later. If you 'Allow' the 'MAC Restrict Mode' and have an entry only for your IoT device(s), only those MAC address(es) are allowed to connect to the IoT wireless network. You would likely only maintain your IoT Wireless Access Point from one of the LAN ports later (even have a '/30' space with only one DHCP client IP address for that computer, and "reserved" IP address(es) for your IoT device(s)).

For a "guest" network it would be the reverse: 'MAC Restrict Mode' would be set to 'Disabled' until you have neighbor(s) find that open network, then you set it to 'Deny' for their MAC address(es) to block them!  Why give them free (even if you are limiting bandwidth) Internet? It is for your guests!


Click on the 'Global Settings' sub-item. The image below is unedited defaults, with some recommendations. The wireless channel (only the 2.4GHz bands on this device - but it is for "guests" and IoT) is shown as 'Auto', but you might want to set it to an out-of-the-way specific channel not bordering your main wireless networks. Set it to '20MHz in Both Bands' rather than '40MHz' to avoid a wider channel footprint. Unbelievably you are trying to un-optimize the two scenarios of an isolated IoT with low bandwidth needs and your limited "guest" wireless.

Tune the 'Basic Rate' down. Again, 'Disable' the 'WMM (Wi-Fi Multimedia)' setting. And immediately above that is an interesting item of 'Transmit Power'. From full power ('100%') there are options to decrease the level in steps of 20% (So other selections of '80%', '60%', '40%' and '20%'). If the wireless signal reaches your IoT device(s) at 20% strength, why have it powered any higher? Put your "Guest WAP" in a location where your guest(s) will be, then cut the transmit power so it isn't going as far as your neighbor's house.

As a final step for this section will be to know how to determine the MAC address(es) of a device by connection to the VisionNet M505N modem. I prefer to select 'DHCP' (showing both wireless and wired LAN connections that are receiving a DHCP IP address from the modem) rather than 'Wireless Clients' under the 'Modem Statistics' menu item. A MAC address is a unique identifier by that interface of the device (and the wireless and wired connection for a laptop would have a separate MAC address for each), the first half is for the manufacturing "vendor". At a later point I will have a more specific blog entry covering MAC address conventions, but for now, you can use this information to create "reserved" IP addresses and allowing or blocking devices by the MAC address they have.

Please stay tuned for further entries in this multi-part series, we are completed with the basic security and isolation techniques for these wireless scenarios, but there are even more security features to come!

Friday, August 19, 2016

Re-Purposing VisionNet M505N Modems as Wireless Access Points, Part Two: LAN Settings

Continuing on with a multi-part series we are entering into the VisionNet M505N web interface once again, this time selecting the 'LAN' menu item. Rather than providing specific entries for the settings (which will differ by need between the "guest" wireless and IoT device isolation functionality) I will give guidance on what you might choose. In our scenarios, small networks would be used in practice, without worry of interfering with other "private-side" networks (as a friend tells me, a great future topic).


For recommendations on a guest network, I will provide two different examples. Again, the topic of subnetting will come in later blog entries, so if you don't understand all of the mechanisms just plug in the values I provide. Your guests will likely never need more than 13 addresses active at the same time, so the first suggestion is an 'IP Address' of 192.168.1.1 and subnet mask of '255.255.255.240'. The addresses will range (which you will enter for the 'DHCP Server' portion below) from "192.168.1.2" in the 'Start IP Address' field to "192.168.1.14" in the 'End IP Address.

I'll cover the remaining DHCP entries in a moment. If you want an even smaller guest network of five available IP addresses in the DHCP pool, set the same 'IP Address' for the modem, but change the 'Subnet mask' to "255.255.255.248" (keeping the subnetting simple for now). Your 'Start IP Address' for the 'DHCP Server' will also stay the same, but change the 'End IP Address' to "192.168.1.6".

I recommend setting the 'Primary DNS server' and 'Secondary DNS server' the same as the modem address (in our examples, "192.168.1.1"). This will actually help mask the actual DNS server addresses (whether public DNS or for a server you have in either the DMZ network or routed to another interface within pfSense). Additionally, I recommend setting a lower DHCP server 'Lease time (hour)'; "2" (for two hours) is a good choice for a guest network.

Entries for an "Internet of Things" Wireless Access Point network could be like the smaller choice (five available IP addresses) or as a "/30" ("CIDR notation", which will be covered in subnetting topics) that only would have room for one "IoT" device (until we cover "reserved IP addresses" in a moment). The entries for that would be the same 'IP Address' of "192.168.1.1", but a 'Subnet mask' of "255.255.255.252" (still keeping our subnetting simple). The 'Start IP Address' still remains the same, and this time, you are also entering the same value for the 'End IP Address' (don't worry, it still works).

We can create "reserved" IP address(es) if we learn the "MAC address" of what device we want to have that IP address. A MAC (Media Access Control) is a unique identifier for every interface able to establish a network connection. The MAC address conventions will also be covered in a later blog entry. Note that we can use this feature for both "management from an ACL" (Access Control List) to be able to securely configure or check the Wireless Access Point later, or for an IoT device entry. The reserved address(es) do need to be within what you have set for the subnet (by the 'Subnet Mask' entry) but outside the range of the DHCP pool.


In a later topic of this series, I will cover setting up an Access Control List on the VisionNet M505N modem. We are also leaving the 'Enable LAN side Firewall" unchecked at the moment, but will return to this powerful setting later as we cover security aspects. For now, we are only going to adjust one possible security setting of turning off uPNP. Click on the 'Security' menu item, then the 'uPNP'  listing below it. Uncheck 'Enable UPnP' and click on the 'Apply/Save' button.


Next time we will look at wireless settings and later further security on the M505N. Leave comments and questions below. Please stay tuned!

Re-Purposing VisionNet M505N Modems as Wireless Access Points, Part One: PPPoE Server


Building on my earlier topics of an "Internet of Things" isolated network and "Guest" wireless at my residence, I am now providing some details of how I use the "PPPoE Server" functionality of the pfSense firewall along with VisionNet M505N DSL modems as Wireless Access Points. The "re-purposed" (using something differently than it was intended) modems have some very good features that can easily be used to lock down the security and isolate those wireless networks. Follow me in this multi-part series as I show the configuration I have in place.

Setting up the PPPoE Server on pfSense

For this first step, I'm showing how to activate the "PPPoE Server" functionality on a pfSense firewall. If you don't have a DMZ network yet just follow along for the concepts and plan to add one. From within the interface of pfSense, go to the 'Services' menu, then select 'PPPoE Server'. Click on the 'Add' button on the right-hand side.

A "PPPoE Server" only means that we are adding a feature to the firewall that uses the authentication of a username and password to establish an Ethernet connection from another device. It may even be likely that your Internet Service Provider (ISP) uses this method over the DSL or cable Internet connection you have (but using DSL or coax cable instead of Ethernet, the 'E' in "PPPoE"). It is the same concept here, where the re-purposed DSL modem connects to the Internet through the pfSense firewall, but being isolated from the other connections to the same firewall (as you are from the other customers of your ISP).

Other concepts that I want to reinforce are planning and documentation. Open a spreadsheet to track the settings that you are going to enter. Every time you make changes to the plan, update that documentation. Here is the table we are going to use as a guide:

If you don't understand "subnetting", I plan to have future blog entries for learning that network skill. For now, you can mimic my example of a small subnet of six usable IP addresses, and another address outside that group.  Keep in mind that these are addresses within your DMZ interface IP space:



Back to our PPPoE Server configuration. Check the box to 'Enable PPPoE Server". It will be in your 'DMZ' (or a network you have named for the same purpose). I've chosen to have the values of '4' as the 'Total User Count' and 'User Max Login' for now. These do not need to be very high values. For the 'Server Address' use the "unused IP" address from the chart we made (in my example, "192.168.100.10"). The "Remote Address Range" is the "Network Address" of the subnet ("192.168.100.0" in my example). The 'Subnet mask' is in a form called "CIDR notation", and slightly confusing because it doesn't show the leading slash ("/29" in my example to denote the size of the address block, equivalent to the form "255.255.255.248" you may see elsewhere).

Your choice of a 'Server Address' and the subnet for the clients ('Remote Address Range' and 'Subnet mask') is required to be within the DMZ address space, but should not overlap the address of the firewall on that interface. What that means is if your firewall interface address is at the lower end of that address space (for example, 192.168.x.1, the subnet (a '/29' in our example) cannot be at the lowest possible range of the DMZ address space. A possible recommendation is to have the address of your DMZ interface at 192.168.x.254 and the 'Remote Address Range' set as "192.168.x.0".


You can use your public-side DNS server addresses (I lock my DMZ interface to only allowing that for DNS resolution), at a later time I am going to relocate a couple NAS appliances to my DMZ interface that will be running DNS services (and will likely be covered in a blog entry). Scroll to the bottom of the page. This is where you will enter the PPPoE usernames, passwords, and IP addresses you documented for the subnet above. 'Save' and 'Apply' the changes.

PPPoE Client on VisionNet M505N Modem

At a later time, we will change the default username and password, as well as other network settings of the M505N. The default for the units I have is "admin" as a username, "0123456789" as a password. Once you log in to the web interface (Internet Explorer is typically needed for this task because of an older HTML standard, and we want to plug into any of the '1' - '3' Ethernet ports, not '4', the "Omni-Port") you are presented with a device information screen.


Click on the "WAN" menu item on the left. "ETH Interfaces" should be selected for being the first menu item. Select the following choices and 'Apply' the changes:


Now select the "WAN Services" menu item below that. If you have a DSL entry, check the "Remove" box in the table, then on the 'Remove' button. Remove the entry from "DSL Services" the same way, and return here. Click on the 'Add' button.


Make sure 'eth3/ENET4' is selected in the combo box, then click on the 'Next' button:


Make sure "PPP over Ethernet (PPPoE)" is selected, then click on the 'Next' button:


On this screen you will put in the username and password you set in pfSense earlier. 'Enable NAT' and 'Enable Firewall". Note, if you want to "daisy-chain" another WAP set up for PPPoE authentication in the same way (I haven't experimented with further possible IoT isolation this way) check 'Bridge PPPoE Frames Between WAN and Local Ports' to make this possible. Click on the 'Next' button once you are ready to advance.



Make sure 'ppp0" is in the first pane on the left for both the Default Gateway and DNS pages, and click the 'Next' button on each page in turn. 'Apply/Save' the settings. When you are returned to the WAN Services page, select the "Omni-Port Interface" and click on the 'Apply" button:






You should now be able to connect an Ethernet cable from the "Omni-Port" of the M505N to your DMZ interface, and it should authenticate. Verify connectivity and wait for the next article on further M505N settings. It's coming soon!

Wednesday, August 17, 2016

Isolating "Internet of Things" Devices Under pfSense - Network Layout

This entry is an expansion of topics I covered back in April - "Internet of Things" Isolated Networks and Guest Wireless Access Point Security. More specifically I will be describing my (home) network configuration under pfSense, however, the same methodology can be applied to an Ubiquity EdgeRouter X like I have in my office at work. I currently don't have any "IoT" devices  at my workplace, so I welcome offers to buy me an Internet-enabled fridge for further testing.

My pfSense firewall at home has four "interfaces" - network connections  to it: WAN (Wide Area Network) through a bridged modem to the Internet, my LAN (Local Area Network) which has most of the systems and devices for me and my family, an "Administrative" network without a Wireless Access Point (WAP) for administering all of that network infrastructure and firewall, and a "DMZ" network (the same concept as wartime, where you have devices and systems that shouldn't be in contact with those on your LAN) that is locked down by filtering outbound ports and limited in bandwidth.


In particular, I am going to describe my DMZ interface and the Wireless Access Points I use for "guest wireless" and IoT devices. Each authenticates with a "PPPoE" username and password to the DMZ interface of my pfSense firewall through their "WAN" interface. Management through their "LAN" interfaces (including wirelessly)  is turned off, wireless clients are isolated, uPNP functionality turned off (as it also is for the DMZ and "ADMIN" interfaces on my pfSense firewall), and on the IoT WAP, the "SSID" (wireless network name) is not broadcast.

When the Wireless Access Points authenticate to the pfSense PPPoE service (I recommend allowing more than one username and password session to be active at a time) they are assigned an IP address on the DMZ interface. Since that network is not allowed to access other networks from the firewall (with the exception of the "WAN" Internet, but heavily port filtered) an IoT device can't be used to attack systems on the LAN(s) or even the "guest" network. They are "isolated" to only link their data to the Internet where you retrieve it.

In my home network, I have a Honeywell thermostat (offers to buy me Nest thermostats and security/smoke detectors are also appreciated) that "phones home" to the Honeywell network to report its current conditions. Then I use an app from my cell phone that connects (whether I am actually at home or elsewhere) to retrieve that data. There is never a direct link from the thermostat to my phone, so it is an excellent IoT device to be isolated.

The Ubiquity EdgeRouter X also has a PPPOE server that can be set to any LAN interface, so the same concept could be used there as well. I re-purpose DSL modems (specifically the VisionNet wireless units, although other brands can have the same functionality) to be used as WAPs, so their "LAN" is just as isolated as it would be to another modem on the same ISP. That is my solution, comment below and stay tuned for other topics!

Sunday, August 7, 2016

Ubiquity EdgeRouter X WAN Subnet and Remote Access Configuration

For this topic, we are continuing to configure the Ubiquity EdgeRouter X, this time for a public-side subnet, access to devices on that subnet, and secure access to the EdgeRouter X only from defined locations (an Access Control List). Note that I described the EdgeRouter X as a firewalled router for a single Local Area Network (LAN) to access the Internet last time since that is a much more common scenario. The topic today could also be used to set up two separate LANs accessing the Internet through the EdgeRouter X as well.

This could be helpful to set up a separate DMZ network for guest access and/or your "Internet-of-Things" (IoT) devices. Just be aware the EdgeRouter X WAN2-LAN2 wizard configures a single port ('eth1', without the Power-over-Ethernet pass-through) for this "secondary" network, and all remaining ports are for the "primary" LAN ('eth2', 'eth3', and the PoE pass-through 'eth4', WAN access is through 'eth0'). You will need an Ethernet switch or Wireless Access Point (WAP) if you need more connections or access on that network [EDIT: or later firmware now released fixes that issue].

In my instance, I have an HP LaserJet printer (with JetDirect network connection) on a public-side IP address for use with Google Cloud Print (my host is a Server 2003 R2 system on my home network, so it didn't break with the "Stable" Chrome browser version 52 update). I will show which port(s) to open for that remote printing as well, to demonstrate how you could have services that need to be accessed from the Internet on that network. The HP LaserJet has an Access Control List that you can set (as did the IP Camera I used at one time), but the EdgeRouter X further locks it down by port numbers.

To get started, log-in to the EdgeRouter X with the account we set up at the end of the last topic, then click on the 'Wizards" tab and select the "WAN-2LAN2" wizard as we did before. I upgraded the EdgeRouter firmware before this topic, so now we have an option to preserve the account we set up without needing to revert to the "ubnt" default account. Since we are wanting the EdgeRouter X to have all traffic pass through it (including the small public-side network it will manage) we are going to "bridge" the Internet modem (in my case, DSL) and use PPPoE authentication from the EdgeRouter X (if you need help with this area, contact your Internet Service Provider, ISP).


If you are setting up a different "secondary" LAN enter the appropriate IP address and subnet mask. Note that the wizard protested that I had enabled the DHCP server for my small public-side subnet, so I unchecked that box before continuing (with one device set with a static IP address I didn't need it anyway, and may see if I can turn it on later if I connect an Ethernet switch there. Also, note that I specified the wrong subnet size (as a '/30' rather than a '/29') that I corrected after the Edge Router X rebooted.

As before, it is best to configure the EdgeRouter X from the LAN we set up connected to either the 'eth2' or 'eth3' connection. The EdgeRouter X turns off the PoE pass-through with any reconfiguration, to be safe that you aren't changing the device connected to that port and damaging it. After it has rebooted you can turn on the PoE functionality as we did in the first topic.

Once enabled your network(s) should be running again under default rules. I changed the "gateway" IP address of my subnet since the EdgeRouter X is now managing it, so don't forget to make the needed adjustments if necessary. The gateway address (the way out to the Internet) will be the IP address you set for the "secondary" network in the wizard.

We will now add the needed ports (HTTPS, port 443 TCP, access for a web interface of the printer, and for the "RAW" printer data put on port 9100 TCP) for that small public-side subnet. Select the 'Firewall/NAT' tab, the 'Firewall Policies' tab, then 'Edit' the "WAN_IN" ruleset by selecting it from the button on the right. Click on "Add New Rule" (my screenshot shows what the two entries will look like once complete).


On the "Basic" tab name the new rule, in this instance we are adding HTTPS access first. Click 'Accept' and 'TCP' for a protocol. We won't be changing anything on the 'Advanced' or 'Time' tabs. Click on the 'Source' tab and specify the appropriate network address(es) with their subnet. Don't enter anything for the ports, as that will be handled from the 'Destination' tab. We are also separating the rules rather than listing the ports together, as I want to see the web interface of the printer than the specific locations that are sending print jobs (over port 9100 TCP.


The 'Source' tab looks very similar to the 'Destination' tab layout shown here. Give the IP address of the device on the subnet. Put '443' (for HTTPS) in the 'Port' field. Click on the 'Save' button.


You should now have access to the web interface (make sure you specify "https://" in the web browser). Add the "RAW" printer data port 9100 TCP as appropriate as well. Test printing to make sure it works. We have the subnet working like it is supposed to, managed by the EdgeRouter X!

Now on to adding secure remote access to your firewall interface (both HTTPS and SSH). This will also be from the 'Firewall/NAT' and 'Firewall Policies' tabs, but the "WAN_LOCAL" policy. Add a new rule, naming and adding the same entries to the 'Basic' tab before. Provide the appropriate entry on the 'Source' tab, again leaving the 'Port' entry blank. On the 'Destination' tab it will be slightly different this time, where we enter both 'Port' entries of "22" (for SSH), a comma (no spaces), then "443", and select 'pppoe' from the 'Interface Addr' choices [EDIT: note you can also have the defined port names of "ssh,https" in place of the numbers].


You now should have access remotely to your EdgeRouter X. I plan to investigate whether aliases can be used like the pfSense firewall (check out my earlier blog entries for those topics). Next, we will start assigning (or "Reserving") IP addresses for equipment on the LAN (where you are running the DHCP service from the EdgeRouter) to further lock down security. Stay tuned!

Saturday, August 6, 2016

Ubiquity EdgeRouter X Initial Configuration

Recently I brought a nifty little - but powerful - device from Ubiquiti called the EdgeRouter X (from online sources, at a cost from $50 to $60). It will become a perfect replacement for an old SonicWALL TZ150 I have on a small work network. With a single 'PoE' (Power over Ethernet) "pass-through" the EdgeRouter X replaces some components I have been using since my first article about PoE almost two years ago.

The EdgeRouter X is powered by a 12VDC supply, or can have a PoE source of 24VDC applied on the first port ('eth0'). Either source can then be passed to the last port ('eth4') for supplying power to a connected device. Most often that will be a Wireless Access Point (WAP), which is also true for the network I am putting the EdgeRouter X in.



At one time I had an "IP Camera" on that small subnet, and powered it from the same 12VDC PoE bridge shown above. With only one device (the WAP) needing a PoE supply I can remove the PoE bridge and the larger power supply (12VDC @ 8 amps) that it used. Beyond those changes, the EdgeRouter X will be configured from a wizard for the initial configuration leaving my DSL modem handling the small subnet for now. In later articles, I will expand the EdgeRouter X to also handle that subnet, and show how I lock down the networks, enable remote access, and assign "reserved" internal IP addresses.

We begin from the basics: If you run the configuration wizards, even after adding another administrator account, you are prompted to reset the unit to the out-of-box defaults (don't worry, the wizard guides you through the process). It was easiest for me to connect to the 'eth0' port with the EdgeRouter X powered conventionally with its 12VDC adapter. Set a static IP on the system you will be using to configure the network of 192.168.1.2, subnet mask of 255.255.255.0, and gateway address of 192.168.1.1 (you can leave the static DNS entries blank for now).

Pull up your favorite web browser to the address of 192.168.1.1, and log-in using the default username of "ubnt" and password "ubnt":


Click on the "Wizard" tab on the far right-hand side, and select the "WAN-2LAN2" wizard:


Initially, I am setting a static IP address for the subnet on my DSL modem with appropriate entries. Later (as we go into the EdgeRouter X managing that subnet) that will change. I'm also setting up an "Optional Secondary LAN port (eth1)" as a placeholder for that process later. The LAN ports 'eth2', 'eth3', and 'eth4' (the PoE pass-through port) will be used for the LAN (enabling the DHCP server functionality as well). Once you apply the settings the EdgeRouter X will prompt you to reboot:


After the reboot, change the 'eth0' to your WAN connection, and move the connection of your computer to 'eth2' or 'eth3'. Remove the static IP address from your configuring system. Re-navigate to the web address of 10.1.4.254 and log-in with the default credentials once again. You should have default access to the Internet from a LAN connection, next we will turn on PoE pass-through. From the 'Dashboard' select the 'Actions' button to the right of the 'eth4' listing.


Select "Configure", then click on the 'PoE' tab and turn on the PoE pass-through. The system will warn you about the PoE settings (my WAP is the same 12VDC input level) as you 'Save' your changes. After it is complete the WAP should power up if connected, and there will be Internet access through it.


As a final step, we are going to add a new administrative user, and remove the default "ubnt" account. Click on the 'Users' tab, then on the 'New User' button. Enter the credentials (making sure you can remember them) and 'Save'. Log out, then log back in under the new account. Re-navigate to the 'Users' tab and 'Delete' the "ubnt" account.



We have the initial configuration working properly. Next time we will reconfigure for the EdgeRouter X to manage the subnet, and enable remote access (both HTTPS and SSH). Stay tuned!