An Unknown 10.x.x.x Network
-
I had a comcast modem in US CT, that had a "Public IP / 30" and acted fully normal, but also had a 10.x.x.x ip address.
I saw many blocks of that 10.x.x.x on my pfSense WAN IF.Edit:
In fact i now have a Comcast modem in NJ (with a public /29 assigned), and was a bit "spooked" when my colleagues tested it , by plugging a PC in the modem, and "pulled" a 10.x.x.x IP. The PC worked fine, and could browse the internet. The PC using the 10.x.x.x net , used another public IP than was in my assigned /29 , checked via "myip.com".When i setup the pfSense for the "static /29" assigned , that worked too.
So the Comcast modems are strange beasts , that can give out 10.x.x.x ip's on the "inside" , and also serve a "public assigned /29".
I haven't tried both at the same time though, but i saw the 10.x.x.x blocks on the CT site.
/Bingo
-
This is my take on what is going on. They have both "out" in the description but this really with the 461 RID and the rule itself seems to be inbound into wan. With 67 source to 68 dest port.
I would read that traffic as broadcast offer.. You might want to look in your dhcp lease on your wan, who was the dhcp server?
the leases your wan has would be in the /var/db folder, its quite possible the isp dhcp server has a rfc1918 address.
Or it could just be some rouge dhcp server sending out that traffic.. I think the problem, the typo... One is a out rule the other is a in rule, but both of the descriptions say out.
-
@johnpoz said in An Unknown 10.x.x.x Network:
I think the problem, the typo... One is a out rule the other is a in rule, but both of the descriptions say out.
+1
Btw: Nice catch ....
/Bingo
-
Mmm, that rule is expected and it's passing in the broadcast traffic as it's set.
I'll have to check the history there but I believe both those rules are to pass traffic for the WAN DHCP client. Hence they both have the same description. I'm not 100% sure why it was required though.....Steve
-
Mmm, Ok you need both rules there because those do not have 'keep state' set. You need to explicitly allow replies from the server. The description is correct if somewhat confusing.
The history there goes waaaay back:
https://forum.netgate.com/topic/1624/automatic-rules-for-dhcp-client-on-wan-interfaceDust off the m0n0wall archive!
Steve
-
Mmm, in fact given the nature of DHCP as broadcast with unicast reply I expect to need both those rules.
The inbound rule could perhaps be more usefully labelled 'allow dhcp client replies' or similar. -
@stephenw10 said in An Unknown 10.x.x.x Network:
more usefully labelled 'allow dhcp client replies' or similar.
Yeah that would be better ;)
-
@bingo600 said in An Unknown 10.x.x.x Network:
Comcast modems are strange beasts , that can give out 10.x.x.x ip's on the "inside" , and also serve a "public assigned /29".
FWIW I see this a lot. In a business environment Comcast "bridges" and passes the public IP through. However they leave NAT working because one can plug in a laptop and bypass the customer router/equipment, while troubleshooting.
My house has a Netgear cable modem "not a router" that has a private IP and is accessible through pfSense, while pfSense has a public IP.
AT&T DSL worked the same way when I had that, I could get to their router/modem using a private IP, while "passthrough" was enabled to give my router a public IP.
Plus I've seen ISPs use 10.x IPs on their internal network. 20ish years ago we had a T1 at work that did that but still routed the public IP to our office. It showed in traceroutes IIRC.
-
@steveits said in An Unknown 10.x.x.x Network:
Plus I've seen ISPs use 10.x IPs on their internal network.
oh many of them do for sure.. .I have a 10.x hop in my trace..
-
https://redmine.pfsense.org/issues/13505
Should be a 10s fix unless I'm missing something.
-
@stephenw10 said in An Unknown 10.x.x.x Network:
https://redmine.pfsense.org/issues/13505
you didn't want to link this thread to the redmine?
-
Done.
Example confusion!