Home IP Address Scheme Change Q's
-
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. :)
-
Not asking for step-by-step, just for a slight nudge in the right direction.
I could say just RTFM ;)
Fortunately a nudge is just about a step-by-step in this case….
Go to "Diagnostics->Backup/restore" and click on "Download configuration".
Save the file somewhere you remember.
Done.The backup is saved into a single XML file that can be easily restored into a fresh (or any) install:
Go to "Diagnostics->Backup/restore"
Remember where you saved the file and choose it under "Browse".
Click on "Restore configuration".
Wait for the system to restart.
Done.A fairly new (I don't remember the release where it first appeared) feature of the XML file structure is its division into "Backup areas".
If you click on the "Backup area:" dropdown you'll see the possibilities.
Using these you can choose which particular areas you want to backup and/or restore individually.This gives you some wonderful tools for diagnosing problems, especially if you start with a complete backup a reference so you don't worry about messing things up while "testing". I suggest you put it to the test, save your current working config and then (gasp!) restore it again.
If you want to explore the "guts" of pfSense, a peruse of the XML file can be very informative (or very confusing).
Keep asking questions and keep learning, its the only way to survive :)
-
And something else really cool about pfSense is you can restore just sections of the backup (like just Traffic Shaping, for instance).
I only have one FreeNAS but it is RAIDZ2.
-
I only have one FreeNAS but it is RAIDZ2.
I had to look that up. I've not heard of RAID-Z2 (or Z1) before now. Cool stuff.
-
I could say just RTFM ;)
OK - I think that, if there's ONE thing I'm struggling with with regards to pfSense, it's the documentation (or lack thereof). Granted, after I saw your post, I went into the documentation, and did indeed find some entries on config backup and auto config backup (haven't read them yet, but I now know they're there).
BUT - I honestly find it really, really grating that the main reference book, is only available for purchase. I guess I'm coming from FreeNAS, where the whole documentation, which has recently been redone (and is quite fantastic, I believe) is readily available. In fact, it now comes as part of the installer, so it's written to the installation media (in other words, accessible even offline). Is it me or is the currently-available pfSense online documentation a bit lacking…? I'm not saying this is the way things are, just the way I currently perceive them to be.
P.S. - I actually have two separate FreeNAS boxes, each RAIDZ2. =) As the guys on the FreeNAS forums are fond of saying : "RAIDZx does NOT constitute a backup!!!". =)))
-
The wiki is pretty much open to anyone, request an account have at updating it ;)
To be honest, if you can not just look at the gui in pfsense and figure out the basics – then maybe you shouldn't even be using pfsense in the first place..
Pretty much every single option has some note on it, etc. Most pages if you click the ? in the upper right takes you to docs - for example the firewall rules page ? takes you to
https://doc.pfsense.org/index.php/Firewall_Rule_BasicsWhen click to create a rule - pretty much every single option has notes on it, etc. etc..
-
You're right, and the more I play around with pfSense, the more I'm seeing that too. I was referring to OpenVPN more specifically, where I had to tool around with third party guides (one in particular was excellent), that went a fair ways past what the wizard did. But hey - I accept that this is part of open-source. FreeNAS was/is the same, to a large extent, but like I said, its documentation is (now) a fair bit better, I believe.
In any case, I am enjoying pfSense more and more as I tool around with it, and this community so far has been awesome.
-
I would not look to 3rd party guides - they are almost always nonsense and out dated.. If you have questions on how openvpn works - I would consult the actual documentation from openvpn.
I have never had issue with setting up pfsense for openvpn just running thru the wizard. Click, click done and up and running.
-
This thread was great as I've been contemplating the same thing as I wrangle my home office LAN into shape with my new pfSense router.
One thing I'm curious about that I didn't see specifically being called out, why subdivide your network into such small partitions like this:
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)instead of just using a separate class C err.. /16 for each use case?
I'm wondering if it might because of problems broadcasting or multicasting, but I thought that if you specified the subnet mask as 255.255.0.0, it would make those able to propagate through the whole network.. -
instead of just using a separate class C err.. /16 for each use case?
I'm wondering if it might because of problems broadcasting or multicasting, but I thought that if you specified the subnet mask as 255.255.0.0, it would make those able to propagate through the whole network..You could do that if you wished and in some cases it would be desirable (larger enterprise/many user setups) but for home use it gets a little awkward pretty fast.
There's something nice about only having to remember the last octet of a network address to specify your printer or Xbox, etc.The other consideration is when you try and connect to other networks that aren't under your control (VPN, etc.)
Assigning yourself an (overly) large block makes it that more likely you'll be stepping on someone else's subnet and cause yourself routing headaches.The breakdown suggested is pretty thorough - in many home setups too thorough.
I would guess most people could easily get away with only a DHCP, Static, and "other" section given that 40 network devices in a home network is a "big" number.
Indeed I'm sure many people just leave it at DHCP and don't worry too much about the rest.As always it's up to you how intricate you want to make this: Design==Choices.
Please note, I'm definitely NOT knocking SilverJS's effort at structuring his (her?) network.
On the contrary as I said earlier, it's refreshing to see someone think about where their design choices will take them - before they have to say oooops ;)Just my $.02, YMMV.
-
Its a home network not sure why anyone would worry about it.. How many printers are you realistically going to have? For that many how many possible devices do you have? If want to have different segments for say wifi and or say specific types of devices then just create a new segment on different vlan, etc.
For example my normal lan is 192.168.9.0/24 wifi network is 192.168.2.0/24, I have a guest wifi that is on 192.168.4.0/24.. I have ps3 for example on is own isolated vlan 92.168.5.0/24 I have a vm dmz segment of 192.168.3.0/24
Breaking up a /24 for specific types of devices would be great idea if were limited to your 1 /24 that was assigned to you by corp or something. But in a home its just kind of waste of time to break it up into such details.. Not like your limited in how many networks you can have.. You have all of rfc1918 space at your disposal why your breaking up a /24 is silly.
-
Maybe it is - but hey, the OCD in me kinda likes it. =) Plus, honestly, it was about learning networks and such. I'm glad I've done it. Ultimately, I'll never ever fill up all the network slots, I know, and it was beyond overkill, I know that too. But it was fun! I enjoyed just sitting down and plotting this in Excel, planning this out, learning about CIDR and such.
I'm actually thinking about further breakin gdown the "server" segment into two /29 segments (lol!) - one for the servers themselves, and the other for the IPMI interfaces.
-
While guess this is good practice.. As you stated its overkill and your over complicating what should be a very simple network.. I really would just break it out to multiple vlans and practice that way if you want to use /27 or whatever on your vlans have at it.. But just playing with ip space in the same segment is not really all that helpful unless you want to create some specific firewall rules for those machines on those IPs.
Which you could do as well if they were their own vlans and or segments on /24 to make it to read for humans.
-
I'll have to admit to not being that knowledgeable about VLANs (yet! - it's my next area of inquiry), but what is the advantage, for the average home user, of VLANs over something like what I am doing?
-
well they are actually different networks so you can actually firewall between them. Your just using specific ips inside 1 network for different things. Buys you pretty much nothing, other than maybe ability to group ips for firewall rules to the internet currently. Which you could do with aliases anyway.
To be honest I see no point to what your doing other than making what IPs your devices get more complicated ;) and possible breaking of your own rules when you maybe picked out wrong number of ips you wanted for specific types of devices.