DSL, Cable, and another Cable Connection Question
-
First and foremost I am not experienced with pfSense but have used several similar products.
For the purpose of this original post, the network is as follows(172.16.2.0/16) Cable 1 -> |
|–-> |PC| ---> LAN (172.16.1.0/16)
(172.16.3.0/16) Cable 2 -> |I originally tried to setup the above configuration using the official pfSense documentation with no luck.
Along the way I read that pfSense should be basically "plug and play" with a single network connection.
I then tried this:
(172.16.2.0/16) Cable 1 -> |PC| -> LAN (172.16.1.0/16) with no luck.
I entered the interface configurations and unchecked "block RFC's" etc. etc.
The address used is out of my control, but this should be possible.
Anyone who can point me in the right direction, it would be greatly appreciated.
Thanks
-
Forgot to mention, pfSense is actually running on a VM within ESXi 4.x.
With the latter diagram, a client can access the pfSense PC @ 172.16.1.254. The pfSense box cannot ping the default gateway.
If I connect my laptop directly to the 172.16.2.0/16 network, I CAN ping the 172.16.2.0/16 default gateway (172.16.2.1), so ICMP is enabled.
ESXi built in firewall perhaps?
Rules required?
Static routes required?
Thanks
-
Your subnet masks are wrong. For the 172 range, the usual is /12, not /16. You have overlapping networks.
-
Thanks for the reply, but are you sure?
172.16.x.x - 172.31.x.x/16?
Class B?
-
RFC-1918 stipulates 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. All of the subnets you enumerated end up in 172.16.0.0 after applying the /16 mask.
-
So my internal network should be as follows:
Internal: 172.16.1.x/255.240.0.0
WAN1: 172.16.2.x/255.240.0.0
WAN2: 172.16.3.x/255.240.0.0
Or, do I need to break it down further?
-
You're still not quite getting it. /12 means the upper twelve bits of the network address are significant. You need to make the second octet unique in the range of 16-31. e.g. that block of private IP is in the range of 172.16.0.0/12 to 172.31.0.0/12. So for example, 172.16.0.0/12, 172.17.0.0/12 and 172.18.0.0/12.
-
Sad that I have forgotten as much as I have….
172.16.x.x = 10101100.00010000.x.x
... meaning
From here > 0001| < To here -- is usable -- 0001, 0010, 0011, etc.
So, for my subnet mask I would use 255.240.0.0 to reflect this?
Eg:
172.16.1.x/255.240.0.0 for Internal.
172.17.1.x/255.240.0.0 for WAN1
172.18.1.x/255.240.0.0 for WAN2Forgive how much I have forgotten here.
Thanks
-
Yes, this should work :)
-
Could I continue to use /16 – so much easier? 8)
Again, thank-you for the quick and positive responses, even to stupid questions I really should have known the answer to (/me looks at Cisco certs and shakes fist)
-
Sure, as long as you keep the upper 16 bits unique. BTW, this pain is one reason I hate the 172.16-31 address block :) I always use either 10.x.x.x or 192.168.x.x :)
-
Thanks – never been a fan either.
However, the company I work uses both the 192.168.x.x and 10.x.x.x ranges so the VPN application pukes when I try to connect.
Ty, I'll make these changes and get back to you with (hopefully positive) results.
-
Keep us posted…
-
Could I continue to use /16 – so much easier? 8)
Again, thank-you for the quick and positive responses, even to stupid questions I really should have known the answer to (/me looks at Cisco certs and shakes fist)You could just use /24 instead and be done with it - that gives you 3 unique networks (172.16.1.0/24, 172.16.2.0/24 and 172.16.3.0/24). I'm not sure why danswartz is so tied to it having to be treated as a single /12 - the whole point of CIDR is that you don't need to do that.
I'd also point out that 172.16/12 covers 172.16.0.0 to 172.31.255.255 as a single network. The examples he provided of 172.16.0.0/12, 172.17.0.0/12 and 172.18.0.0/12 are all the same network - 172.16.0.0/12:
172.016.000.000 - 10101100.00010000.00000000.00000000
255.240.000.000 - 11111111.11110000.00000000.00000000
network - 10101100.00010000.00000000.00000000 (172.16.0.0)172.018.000.000 - 10101100.00010010.00000000.00000000
255.240.000.000 - 11111111.11110000.00000000.00000000
network - 10101100.00010000.00000000.00000000 (172.16.0.0)
-
Havoc, you misunderstood my point. I was not advocating for /12 or anything else, just pointing out that the /12 defines the RFC-1918 network range (one of the three, at any rate.) Certainly he can subnet it as he wishes, as long as his netmask is correct.
-
Your posts were very confusing on that point, particularly here:@danswartz:
You're still not quite getting it. /12 means the upper twelve bits of the network address are significant. You need to make the second octet unique in the range of 16-31. e.g. that block of private IP is in the range of 172.16.0.0/12 to 172.31.0.0/12. So for example, 172.16.0.0/12, 172.17.0.0/12 and 172.18.0.0/12.
and@danswartz:
Your subnet masks are wrong. For the 172 range, the usual is /12, not /16. You have overlapping networks.
Yes, your point about wrong subnet masks and overlapping networks is right, but there is no "usual" subnet for any prefix and the prefix you provided was not helpful to the OP. Particularly your response to@np247:
Eg:
172.16.1.x/255.240.0.0 for Internal.
172.17.1.x/255.240.0.0 for WAN1
172.18.1.x/255.240.0.0 for WAN2saying@danswartz:
Yes, this should work :)
is obviously wrong.
-
Ugh, this should teach me to post on low blood sugar :( Yes, the /12 is not in fact correct in that context. As far as CIDR goes, I agree with you, my point (not well put) was historical. His /16 would have been fine if he had moved the 16, 17 and 18 up one octet (172.16.0.0/16, 172.17.0.0/16 and 172.18.0.0/16).
-
I wonder how this will end with IPv6 and RFC4193 if there are already confusions with /8, /12, /16 subnets.
Where will this end with /48 ~ /64 subnets? :D
