An Unknown 10.x.x.x Network

NogBadTheBad

@johnpoz I missed the out part

johnpoz

@nogbadthebad my brian still a bit fuzzy, and eyes a bit wonky - but something seems off with that traffic to me.

Cut clearly if its coming from his wan, than that 10.x address would be his..

isomillennium

@johnpoz Thank you for your reply.
I have been seeing it here and there every few hours. I might have seen it 10 times .. then i decided to share with you all to see what you all think. I havent seen it yet this morning ..

And OK i Willl try to do a sniff and Investigate. Thank you

johnpoz

@isomillennium and your saying you have no 10.240.181 addresses on pfsense at all, not a vip, not a vpn connection? Nothing..

Back to your "worried about" while I wouldn't be so much worried as to what it is. But I for sure would want to understand what it is.

allow dhcp client out WAN

That says to me its the pfsense itself dhcp client. But a source 67 to broadcast 68 says its a broadcast offer, so dhcp server on pfsense, but then why does it say client?

Are you on a pppoe sort of connection you would have a pppoe connection on top of your actual physical wan, with different IP ranges?

So the rules are listed as such in pfsense

[22.05-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep dhcp
pass in  quick on $WAN proto udp from any port = 67 to any port = 68 ridentifier 1000000461 label "allow dhcp client out WAN"
pass out  quick on $WAN proto udp from any port = 68 to any port = 67 ridentifier 1000000462 label "allow dhcp client out WAN" 
[22.05-RELEASE][admin@sg4860.local.lan]/root:

See how that log says source port is 67 to 68.. That would be a in rule? Not out rule.. Notice the rule id, pretty sure those are going to be the same ids across machines. So I am confused where what is causing that log entry myself. I don't log that sort of traffic but might turn on logging for those rules, to see what mine shows.

Ah - hmm just noticed they have a typo in description. Notice how both of those rules say out wan.. But clearly one rule is in wan and other is out wan.

edit:
To be honest the typo is making more sense now. If you were seeing some dhcp server on your wan network send out a broadcast off from 67 to 68, then with that description say out wan for rule 461, that would explain everything - you seeing dchp offers on your wan from something else on your wan, could even be the isp, etc.

isomillennium

@isomillennium I dont have a 10.240.x.x network. All I have is a cable modem/router, which I disabled the router functionality on so i can hook it up to the Netgate 1100 on the Wan interface. ANd on the Lan side of my NetGate I have a Wavlink Wireless adapter that is bridged to Netgate Lan interfce. And that Wireless adapter is connected from its LAN port to NetGate Lan port so they can be on the same network 192.168.1.0/24.

I have a couple of Google Chromecasts hooked up to my TVs ..
ANd my OpenVPN Server is 10.0.8.0/24.

Nothing with a 10.240.x.x

I just realized i see these messages every minute.. The reason i wrote that i havent seen them since last night was becasue I had the "Log packets matched from the default pass rules put in the ruleset" checkbox unchecked in the settings of the logs since i posted this..

bingo600

@isomillennium @johnpoz

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

johnpoz

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.

bingo600

@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

stephenw10

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

stephenw10

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-interface

Dust off the m0n0wall archive!

Steve

stephenw10

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.

johnpoz

@stephenw10 said in An Unknown 10.x.x.x Network:

more usefully labelled 'allow dhcp client replies' or similar.

Yeah that would be better ;)

SteveITS

@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.

johnpoz

@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..

stephenw10

https://redmine.pfsense.org/issues/13505

Should be a 10s fix unless I'm missing something.

johnpoz

@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?

stephenw10

Done.
Example confusion!