Home IP Address Scheme Change Q's
-
Hi gents,
Go easy on the n00b, plz. =) This is not fully pfSense-related, but I figure guys on this forum would be as knowledgeable as any on the matter. If I'm overstepping my bounds, please let me know and I'll amend as required.
So, I'll be putting up a pfSense rig up soon (specs in sig). However, at other peoples' advice, I will also be changing my private IP address numbering scheme. I'm currently using a 192.168.0.xxx/24 scheme, which could very well pose a problem when I want to use a VPN, which is part of the intended use. However, to ease into things, I'd rather change the scheme now (the ISP-supplied consumer router is a D-Link DIR-825), and then, once that's complete and everything's tickety-boo, basically replace the D-Link with pfSense, and slap in a WiFi AP (an older Asus RT-N12 that I've already flashed with DD-WRT - I've tried this using my current config, by shutting off the wifi on the D-Link, and it worked beautifully).
But I'm not 100% sure how to go about this. I've done a fair bit research and I've got an idea of the way to do things, but I'd like to seek out the opinion of the folks here.
I guess the very first question is : should I get pfSense running first, THEN change the scheme, or do it the way I currently have it planned?
Either way, the steps will largely be the same, I assume. Here's how I was thinking of doing things : you guys tell me where I'm going wrong. New scheme will be 172.18.132.xxx/24.
1. Set up an Alternate IP Config in my main Windows computer, so that the computer can both be on my current scheme, and the new one. I'd use a static address of 172.18.132.30 in the alternate config, as that's an unused address in the new one. This way, I can access the router if ever I need to, plus FreeNAS GUI's;
2. Log in to the router, change its IP address to 172.18.132.1, and change the DHCP pool to 100-199;
3. [Edited out - was about FreeNAS, but decided it was too FreeNAS-specific for this forum.]
4. Basically go around rebooting, or at least somehow restarting network services, of all my computers. Should I set them up with static IP's until I have the DHCP reservations up?
5. Reboot all wireless clients.
Am I missing anything?
Thanks!
-
My vote would be for pfSense first if only because the tools available to you in that environment are typically better than a consumer router.
My suggested plan of attack:
Get pfSense up and running.
Part of the initial install will ask you for the LAN address you want. Just put in 172.18.132.1 and use 24 for the network "bits" (this creates a LAN network of 172.18.132.0/24 with pfSense using 172.18.132.1 for its LAN NIC).Let pfSense handle DHCP on LAN, you can use 100-199 for your pool if you wish, but a more "subnet wise" range would be 64-127 (probably won't ever matter to you, but could make network rules and math easier in the future for some special case scenarios)
Set all your devices to use DHCP and let pfSense assign them addresses. I typically let a new device get an address initially, then I go to pfSense "Status->DHCP Leases" and look for the new IP assigned. Click on the "+" at the end of the line and give the device a static address (OUTSIDE of the DHCP pool). Restart the device and your done.
Login to the DLINK router and DISABLE DHCP. You want to set the DLINK as a wireless access point only. You may have to change its internal LAN address to something on your 172.18.132.x network (I typically use high numbers .200,.250, etc. for this). This will let pfSense will hand out DHCP on your wireless network. If you want use a different network for your wireless devices you can plug the DLINK into a different NIC on pfSense and you're good to go
Reboot as necessary and watch everyone smile…..
Let us know how this works out for you and good luck!
-
"192.168.0.xxx/24 scheme, which could very well pose a problem when I want to use a VPN"
This is true.. But have yet to run into it myself that I could not work around.. I keep meaning to renumber my networks at home - just never got high enough on my stuff to do list ;)
But as per divsys - just set everything to be dhcp and pretty simple to get everything back up, then just setup reservations for them on the IPs you want them to have and should be good to go.
-
My favorite ugliness with OpenVPN is linking my network to two others that both happen to be 192.168.0.x (or one of the other "standard" subnets).
Ann it never fails that I need to access both those sites simultaneously…..I've had enough clients where that's popped up that I now insist on reassigning subnets unless there's a REAL reason not to.
Ah well, makes life interesting :P
-
Yeah its good practice to run your network on something odd ball, just so you don't run into the vpn issue. 90% of the time I am just vpn'ing from work which uses 10 space so never been a issue. But I should really do this too… Think I will get started to night on my smaller vlans.
-
I purposely set my network and my clients' networks to something in the 10.x.x.x/8 range. Less probability that it'll have conflicts. There's nothing more frustrating that visiting a hotel or other LAN that is 192.168.1.0/24 or 192.168.0.0/24 and having to connect to another network with the same IP range.
I use things like my client's street address to give them a range. For example, I have a client with a street address of 1170, so their network is 10.11.70.0/24. I got lazy and gave another client 10.23.145.0/24.
It's one of the first things I do when I deploy a new router on a network, get it immediately off of 192.168.x.x.
-
Thanks for the great responses!
My vote would be for pfSense first if only because the tools available to you in that environment are typically better than a consumer router.
My suggested plan of attack:
Get pfSense up and running.
Part of the initial install will ask you for the LAN address you want. Just put in 172.18.132.1 and use 24 for the network "bits" (this creates a LAN network of 172.18.132.0/24 with pfSense using 172.18.132.1 for its LAN NIC).OK - I've already got pfSense installed on the computer in sig. I configured it, for testing and such, with an IP (in line with my current IP address scheme) of 192.168.0.125. From console, should I simply use Option 1 (Assign Interfaces - I assume this will also enable the auto-detect protocol?) or Option 2 (Set Interface(s) IP Address)? I'm leaning towards 1, but what are your thoughts?
(I guess I could also reset to factory defaults…)
Let pfSense handle DHCP on LAN, you can use 100-199 for your pool if you wish, but a more "subnet wise" range would be 64-127 (probably won't ever matter to you, but could make network rules and math easier in the future for some special case scenarios)
Could you please elaborate what you mean by "network rules"? Math, I can see (you used the second block of 64 [63, technically] out of four), but rules? Just curious - trying to avoid having to do this again. =) For reference (figure I might as well post it), this is the proposed organization I had in mind :
1: pfSense
2-9 : Network Devices
10-19 : Servers
20-49 : Statics
50-59 : Printers
60-79 : IoT
80-99 : A/V
100-199 : DHCP Range
200-209 : Jails (FreeNAS-ism - although I suppose pfSense could support them too, given it's FreeBSD-based…!)
210-254 : ReservedSet all your devices to use DHCP and let pfSense assign them addresses. I typically let a new device get an address initially, then I go to pfSense "Status->DHCP Leases" and look for the new IP assigned. Click on the "+" at the end of the line and give the device a static address (OUTSIDE of the DHCP pool). Restart the device and your done.
That is indeed one of the COA's (Courses Of Action) I had in mind. It'll probably be easiest indeed. I'm assuming that "+" will then take me to the DHCP Reservations page? Or do you mean something else by "static address"?
As for WiFi - yeah, I was basically going to completely take the ISP-supplied D-Link out of the picture. PfSense will replace its routing functions, and I'll use an Asus RT-N12 of mine (already DD-WRT flashed) as an AP. This way, when I move, I take everything with me, nothing changes.
I purposely set my network and my clients' networks to something in the 10.x.x.x/8 range. Less probability that it'll have conflicts. There's nothing more frustrating that visiting a hotel or other LAN that is 192.168.1.0/24 or 192.168.0.0/24 and having to connect to another network with the same IP range.
I use things like my client's street address to give them a range. For example, I have a client with a street address of 1170, so their network is 10.11.70.0/24. I got lazy and gave another client 10.23.145.0/24.
It's one of the first things I do when I deploy a new router on a network, get it immediately off of 192.168.x.x.
I thought that many businesses also use the 10.x.x.x typology, so that (according to my readings, anyway), if I work at a business that has a 10.x.x.x once I quit the military, and I want to VPN to work from home, my own 10.x.x.x might conflict with that…thoughts? Not sure how that would work if they use 10.x.x.x/8 and I use 10.x.x.x/24...?
Cuz hey - from a pure typing perspective, I find that 10.21.132.x works fantastically! =) I might even use that then!
-
I purposely set my network and my clients' networks to something in the 10.x.x.x/8 range. Less probability that it'll have conflicts. There's nothing more frustrating that visiting a hotel or other LAN that is 192.168.1.0/24 or 192.168.0.0/24 and having to connect to another network with the same IP range.
I use things like my client's street address to give them a range. For example, I have a client with a street address of 1170, so their network is 10.11.70.0/24. I got lazy and gave another client 10.23.145.0/24.
It's one of the first things I do when I deploy a new router on a network, get it immediately off of 192.168.x.x.
I thought that many businesses also use the 10.x.x.x typology, so that (according to my readings, anyway), if I work at a business that has a 10.x.x.x once I quit the military, and I want to VPN to work from home, my own 10.x.x.x might conflict with that…thoughts? Not sure how that would work if they use 10.x.x.x/8 and I use 10.x.x.x/24...?
Cuz hey - from a pure typing perspective, I find that 10.21.132.x works fantastically! =) I might even use that then!
Yes, many business and ISPs use 10.x.x.x/8. One of my clients, a multinational pharma company, uses 10.101.x.x for many US addresses. My internal work address is 10.0.2.0/24. I don't conflict with any of the pharma's network. I think my ISP may also use 10.100.100.100 for something too, but again, no conflict. It doesn't mean it's bullet proof, but there's a very low probability that I'll hit a conflicting network. And if I do, I'll just add some random (unused at my clients') number to my work LAN like 10.231.173.0/24. Ugly looking subnet, but only another knuckled like myself would pick it.
I think you have a winning IP range there! :D
-
OK - I've already got pfSense installed on the computer in sig. I configured it, for testing and such, with an IP (in line with my current IP address scheme) of 192.168.0.125. From console, should I simply use Option 1 (Assign Interfaces - I assume this will also enable the auto-detect protocol?) or Option 2 (Set Interface(s) IP Address)? I'm leaning towards 1, but what are your thoughts?
(I guess I could also reset to factory defaults…)
If your pfSense is already up and OK, then you can simply use Menu Option 2 to reassign a new IP address to LAN. Option 1 would normally be used if you need to change which physical NIC is used for LAN/WAN/OPT1 or when you add an extra NIC. That being said, either would work fine, Option 2 would simply be a little faster. Factory default would just reset the LAN NIC to 192.168.1.1
Could you please elaborate what you mean by "network rules"? Math, I can see (you used the second block of 64 [63, technically] out of four), but rules? Just curious - trying to avoid having to do this again. =) For reference (figure I might as well post it), this is the proposed organization I had in mind :
The "rules" reference has to do with the way the "math" works out. As you noticed I suggested a subnet split on the .63 to .64 boundary. The reason that's handy is due to the way you can easily reference those two subnets. You may have recognized the notation used for various subnets ie. 192.168.0.1/24 which means literally: the address range starting at 192.168.0.1 with the UPPER MOST 24 BITS FIXED. In this case that means the 192.168.0 portion (the first three "Octets") is fixed , only the last 8 bits (the fourth Octet) can change. Since the last Octet can only be 1-254 (255 is not allowed) we get a range of addresses from 192.168.0.1-192.168.0.254 which is all well and good.
But there is nothing saying we have to fix "24" bits, we could lock down the first "25" bits as well. So 192.168.0.1/25 refers to .1 - .127, 192.168.0.128/25 refers to .128 - .254 and 192.168.0.64/26 refers to .64 - .127. pfSense let's us create rules based on subnet ranges like 192.168.47.0/26 so we can more easily reference different parts of our subnets if we've planned ahead. In bigger networks with many subnets, things like 192.168.64.0/18 become important and planning your boundaries is essential.
After that fairly (quasi?) technical discussion, the reality is you can do what you like with your DHCP pool - it's yours after all! The list you gave is as good a plan as any I could come up with - the very fact that you stopped to plan in the first place puts you steps ahead of many others doing "network design". Don't get too bent out of shape over the exact numbers you need, pfSense will give you plenty of tools to make your network shine. ;)
I'm assuming that "+" will then take me to the DHCP Reservations page? Or do you mean something else by "static address"?
Yup, that's it. There's quite the options available on that page (you'll see) but the key two are the MAC address (filled in automatically when you use the "+") and the IP address you want to assign. Most everything else is optional although you might want to think about filling out the "Hostname" (to allow DNS style references by name instead of IP) and the "Description" (to help document your network) fields.
PfSense will replace its routing functions, and I'll use an Asus RT-N12 of mine (already DD-WRT flashed) as an AP. This way, when I move, I take everything with me, nothing changes.
The Asus is an excellent choice especially when DD-WRT gives you full control of all the functions.
I thought that many businesses also use the 10.x.x.x typology, so that (according to my readings, anyway), if I work at a business that has a 10.x.x.x once I quit the military, and I want to VPN to work from home, my own 10.x.x.x might conflict with that…thoughts? Not sure how that would work if they use 10.x.x.x/8 and I use 10.x.x.x/24...?
Cuz hey - from a pure typing perspective, I find that 10.21.132.x works fantastically! =) I might even use that then!
The three "Private" subnet/network ranges defined (by RFC1918) are:
- 192.168.0.0/16 => 192.168.0.x-192.168.254.x (255 Class "C" subnets possible, 65534 addresses )
- 172.16.0.0/12 => 172.16.x.x-172.31.x.x ( 16 Class "B" networks possible, 1048574 addresses)
- 10.0.0.0/8 => 10.0.x.x-10.254.x.x ( 1 Class "A" network possible, 16777214 addresses)
You can use any (or all) of these ranges as you see fit. Businesses (especially large ones) often use range 3) if only because it gives them enough possibilites to design a network for many divisions without having two conflicting addresses.
Your choice of "10.21.132.0/24" is easy to type, and (for you) easy to remember - definitely a winner :D
-
Right on, thanks!
That actually got me thinking about a slight reorganization. I could move my jails (with additional slight renumbers as well) in that spot after 100, do something else from 110 up to 127 (not yet sure what), reserve 128-191, and use 192-254 for dhcp. That would allow me to use /26 for rules in the future should I ever need it, both for the reserved and dhcp pools. Thanks for that!
Right now, the box is hooked up with both interfaces being hooked up to the same switch. It's very ugly, I know - only did that to test and "practice". Point is, I don't know which interest face is which, so I guess I'll have to go with option 1. I just hope I can access the auto detect protocol through it.
-
- (255 Class "C" subnets possible, 65534 addresses )
- ( 16 Class "B" networks possible, 1048574 addresses)
- ( 1 Class "A" network possible, 16777214 addresses)
We live in CIDR times since 1993 or so.
(RFC 1518, RFC 1519, RFC 4632)
Why do some people still reference to an abandoned standard more than 20 years later?Just show your examples as /24 /16 and /8 (or 255.255.255.0 255.255.0.0 and 255.0.0.0 whichever writing you prefer). It doesn't matter how many "Class C" networks 192.168.0.0/16 contains and it's easier to follow anyways.
-
OK, so….first foray wasn't successful at all. The IP address scheme change thing worked out pretty good - no real flaws that I can see so far (but I did have to restart my Replication on FreeNAS...other than that, it really was a total non-event).
The biggest thing is - I had no Internet! Truth be told, I haven't really searched the forums yet to see if this has happened before (I intend to), but I kept getting DNS errors. The error I was seeing in Chrome was "DNS_PROBE_FINISHED_BAD_CONFIG" or some such. Tried two computers (several restarts each, and flushed DNS on both in ipconfig), but no luck. Windows was showing me with access to Internet, but no name resolution at all. So maybe saying "I had no Internet" is not technically correct. It never dawned on me to check Internet connectivity via IP though - duh!
I tried with the Google DNS servers, then manually input the ISP ones (I had saved them on a piece of paper). One weird thing is that, last I checked, the default gateway (in the ISP-supplied router) was 184.160.113.1. When I went to the DNS page in pfSense, the gateway drop-down next to the addresses only said "None" or "Default WAN" or some such, with the address being similar to, but not exactly the same as, 184.160.113.1. I had no option to edit it.
Anyway - I quickly re-installed the ISP-supplied router (whose IP I had previously changed to my new scheme, in case this happened), and everything was just fine and dandy. Internet on all computers, etc.
So, at least I've got my new numbering scheme up and running, servers are purring along, my new WiFi AP is running fine. So, I'll do some research and try to figure this out. For now, it's a simple matter of dropping pfSense instead of the IPS router (the two ethernet cables, essentially), so it'll be quick for experimentation.
Ideas, anyone?
-
1: pfSense
2-9 : Network Devices
10-19 : Servers
20-49 : Statics
50-59 : Printers
60-79 : IoT
80-99 : A/V
100-199 : DHCP Range
200-209 : Jails (FreeNAS-ism - although I suppose pfSense could support them too, given it's FreeBSD-based…!)
210-254 : ReservedThis is how you would get about the same thing but with your groups of addresses on subnet boundaries so you could reference each group with one CIDR if desired.
1: pfSense +
2-14 : Network Devices (x.x.x.0/29)
17-30 : Servers (x.x.x.16/29)
33-62 : Statics (x.x.x.32/28)
65-78 : Printers (x.x.x.64/28)
81-94 : IoT (x.x.x.80/28)
97-110 : A/V (x.x.x.96/28)
129-190 : DHCP Range (x.x.x.128/26)
193-222 : Jails (x.x.x.192/27)
225-254 : Reserved (x.x.x.224/27) -
Interesting! That actually gave me some ideas. I've incorporated my very slight restructuring from before, with insight provided by Derelict. Newest is in pic below (figured it was quicker to simply take a screen capture via Snipping than to type it all out here…).
Of note, the yellow blocks are ones where, in the CIDR version, the numbers are reversed from the legend at the left, in order to follow the proper binary possibilities of the /27 and /28 numbers. Derelict, thanks for pointing me in this direction - I learned yet more this morning as I researched all this. =)
Now that I know that renumbering (a home network, anyway!) is relatively painless, I think I'll focus on getting pfSense up and running before renumbering to the CIDR version. Anybody got any insights on that? (I mean - the whole DNS thing.)
I'll try a full re-install - maybe some setting somewhere is hindering something, from my previous hack job at testing...
-
OK, re-install solved it! I am now typing this and sending data, accessing the Internet, through my pfSense box! Pretty exciting! =)
-
OK, re-install solved it!
How? Just a simple reinstall with all the same configuration? Details are key for helping others down the road.
-
I really wish I could be more specific! But, yes, a re-install with, as far as I can tell, the same configuration. Except that - for the very initial config (wizard), I used my ISP's DNS servers. I replaced them right away though (with the two Google ones), and didn't really see a difference. Seeing as part of the idea for me in doing all this pfSense install was consistency when moving, I figured the Google ones were a better match and I kept them. In any case, I did all that with the previous install too, no luck.
Other than that, I'm really not sure what's different in what I did with the clean install, and what I did with my post-hack-job install to try to make it work in this network. I don't remember all the things I did with the hack job, as I was exploring and trying things out. I must've messed something up somehow, but that's the best I can do, sorry.
-
One really nice thing about pfSense (IMHO) is the ability to capture the setup configuration in a single XML file.
In the future, think Backup,Backup,Backup!If you resort to a full rebuild and have a copy of the last "bad" configuration, you can quickly troubleshoot what went wrong by selectively restoring select pieces of the setup.
It's a great learning tool and you risk very little because you can bring the setup back to known states with a saved "Good" setup.
There really are some great tools in this little package.In case you didn't get the hint by now, I would humbly suggest you make and save a backup of your working config….. ;)
-
One really nice thing about pfSense (IMHO) is the ability to capture the setup configuration in a single XML file.
In the future, think Backup,Backup,Backup!If you resort to a full rebuild and have a copy of the last "bad" configuration, you can quickly troubleshoot what went wrong by selectively restoring select pieces of the setup.
It's a great learning tool and you risk very little because you can bring the setup back to known states with a saved "Good" setup.
There really are some great tools in this little package.In case you didn't get the hint by now, I would humbly suggest you make and save a backup of your working config….. ;)
I most certainly did, thanks. =) And believe me, it was on my mind, I just hadn't gotten there yet. (I'm obsessed about back-ups - I have two entirely separate FreeNAS machines for my data and pictures and such. I'd just put the pfSense config file on them too, to be readily accessed if the worst happened.)
Care to enlighten the n00b a bit? Not asking for step-by-step, just for a slight nudge in the right direction.
Cheers!
-
IMHO, the first six times I set up pfSense for the first time, I reinstalled each time. The system is very powerful and configurable, and with great power comes responsible configuration. I was very irresponsible the first 5x I set it up.
I'm glad you got it working, and punting each time you install is just a rite of passage. :)