Hardware + Supernetting = Hard time installing thus far
-
The only spare server hardware I have to test it out with apparently doesn't play nice with pfSense/BSD. They are IBM x3550 M1 and x3650 M1 servers. It hangs about 36% on a mount. From a few Google searches this seems to be a common problem with the RAID card used. Does this sound right?
I then tried installing on a modified desktop with an added dual-GbE NIC. Now I'm having problems getting connected to it due to supernetting.
We currently have a 192.168.0.0/20 supernet. We will be eventually moving to a 10.x.y.z, but this was put in place because we were running out of IPs and needed to change things fast. When I configure the firewall with an IP (using 192.168.0.1/20) it won't allow anything to connect to it. However if I give it a 192.168.0.1/24 then stuff on the 192.168.0.z subnet can connect to it only. Have you ran into this before? I haven't had problems testing out any other firewalls: Endian, Sonicwall, Meraki.
I'm by no means a network guru myself, but is it because supernetting not a recommended setup? It's not been a fun install so far, but still trying. It looks powerful and I like the hardware & software options. Thanks for the help!
-
I have a site with a private subnet like 10.22.0.0/21 - that goes from 10.22.0.0 to 10.22.7.255 - and works fine. We have various categories of devices spread throughout the "8*classC subnet". It should work fine in the 192.168 private space also.
The main source of error comes from devices that have static IPs hardcoded in them, and people put /24 mask. That means the device can only talk to other things in the same /24 bit of the network that they happen to be in. -
Thanks for the info. Yeah, it seems odd. Everything is in the 192.168.0.0/20 which is a 255.255.240.0 subnet (192.168.0.0-15.254).
For instance when setup like this, they can't see each other …
FIREWALL: 192.168.0.1/20
DESKTOP: 192.168.0.10/20However, like this they can ...
FIREWALL: 192.168.0.1/24
DESKTOP: 192.168.0.10/20... but then obviously none of the IPs outside of 192.168.0.z can get to the firewall.
I've tried a few different IPs in that same subnet such as 192.168.1.253. It's almost as if it's expecting a Class C with the 192.168 range, even though B is capable because I believe 192.168.0.0/16 is still private space.
Any other ideas to try?
-
For instance when setup like this, they can't see each other …
FIREWALL: 192.168.0.1/20
DESKTOP: 192.168.0.10/20However, like this they can ...
FIREWALL: 192.168.0.1/24
DESKTOP: 192.168.0.10/20Any other ideas to try?
By "they" here I presume you mean that particular desktop and that particular pfSense interface.
I presume that particular pfSense interface is always the pfSense LAN interface, always the same physical interface (for example, you don't have 19.168.0.1/24 on vr1 and then try 192.168.0.1/20 on vr2) and that "can't see each other" means that both systems report "no response" when a ping to the other system is initiated (If not, what test of ' seeing each other' are you using?)
It was my experience some time ago that major changes in interface IP addresses seemed to need to be followed by a reboot to clear out memory of old configuration. I wouldn't have thought 192.168.0.1/24 to 192.168.0.1/20 would be such a major change but a reboot is easy. If a reboot doesn't fix it then we can down to more detailed troubleshooting which should begin with you describing how you are testing "seeing each other" and providing more details on what you do to change the network mask.
-
pfsense console option 8 allows you to drop to a standard unix shell and run all sorts of diagnostics.
You can run from the basic ifconfig to check if the interfaces are correctly configured, to ping to check for connectivity, up to tcpdump (which however requires some technical background)