Sunday, October 30, 2016

IT Pro TV Open House



I've just returned from the IT Pro TV "Open House" on October 27th in Gainesville, Florida. It was a fantastic opportunity to finally meet the hosts and staff of IT Pro TV, as well as their new location with five studios. In a moment, I'll show some of the pictures I took both before and during the event. But what better way than to let IT Pro TV's own Don Pezet give you a guided tour to start things off?


As a further interactive experience, I took VR photos of the "Command Center" and all five studios for viewing in a headset like the Mattel View-Master I reviewed almost exactly a year ago. Download the image to your phone having the Google Cardboard app, and they should be listed in the Photosphere area.

The "Command Center", with Wes, Cherokee, and my friend James Ortega

Studio 1

Studio 2 (Who is that on the video monitor?)

Studio 3

Studio 4, with James and Don talking

 Studio 5

For regular photos within the studio area, here are details that have been in front of the cameras in the past, are now, and behind the scenes:

The old Studio 1 backdrop, being readied for re-use

The new Studio 2 backdrop that replaced it

The Leo Laporte bobblehead (more on Leo in a moment)

Close-up of the PTZ cameras underneath the studio monitors

Elsewhere within the building is very nice, here are the walls you also see in the video tour:





And the arcade:

Don's office is the informal "Studio 6", set up with cameras and microphones. Do you know of anyone else with acoustic absorption panels on the wall? Does anyone recognize the portrait on the wall?






On to the celebration:





Lisa and Leo Laporte of TWiT were at the IT Pro TV Open House, here is my friend James Ortega and myself with Leo:

I had a great time, and I look forward to returning to the studios in the future!

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!