Foreign source IPs from LAN from mobile device

anallama

Hello, I was wondering if anyone could illuminate an old noob's understanding of what is going on in the above screenshot.

I've been testing out a a linux-based mobile phone OS, and it has some odd behaviour, such as trying to send and receive MMS messages through Wi-Fi when it is connected to such. I know that this is what is causing these entries in my firewall log based on the destination port, I just don't get why the source IP is listed as an IP from another continent (and assigned to the UK Ministry of Defense, supposedly), rather than from my local network. Can someone help me understand that? some weird internal workings of cellular modems? Probably something ultra-basic that I just don't know enough about to search the internet correctly...

Gertjan

@anallama

Looks like a typical case of a device with it's IP stack all messed up.
Like : the device - a phone, Wifi connected, so it should use the local LAN RFC1918 network, but the MMS program is all confused and thinks it still uses a 4G/5G connection thus a non RFC1918.

Have a chat with this phone. Upgrade it, stop using SMS, or ditch it. I know, silly advise, as I've no details.

pfSense does what it is paid to do : it blocks BS connections.

Btw : my LAN rules :

Disregard my first two rules. The first one is an experiment. The second is translates incoming NUT LAN clients traffic, so it can talk to my pfSense NUT (UPS) server.

Rule 3 and 4 are the two classic rules that you found on LAN when you installed pfSense.
As these rules only accepts traffic from devices using the LAN IP networks, enforced with the "LAN Address" source alias (I've split mine into IPv4 and IPv6) these two rules are the last two that will and should pass traffic.

Technically, the last rule - my own block all rule - should never capture traffic. I even don't want to know what hits this rule, as long as the traffic counter :

stays low.
The exception is what you've shown us : a LAN device starts making up his own IPs and network.
Btw : pf final block rule logging (the 1000000103 rule) is, imho, only enabled for logging in case of 'emergency', so remove the check here :

and you won't see a thing.
I see it like this : it's a free world for everybody. If a device wants to behave stupidly, then I'm all ok, but I don't want to be bothered with it neither.
If I want to see what going on, I activate logging on my own 5th firewall rule, where I have more control over what's filtered, if needed.

My short answer : disregard, disable Default Block rule logging, and remove stupid devices from your network
Btw : android or apple stuff ?

tinfoilmatt

Do you have any open WAN ports?

johnpoz

@anallama why are you hiding the destination IP (is your wan or something)? And how do you know that 8799 is for mms messages - port 8799 tcp is not a registered known port number for any specific service.

How would it this traffic even get sent to your lan interface? Is your lan interface part of a bridge?

The only way traffic should be seen by your lan interface the client thought it was its gateway via a arp for its gateway IP so learned its mac, why would it think your lan interface is its gateway for some 25.x network or it was broadcast traffic, or the inteface is part of a bridge?

what is the destination IP your seeing, can you do a packet capture and capture this traffic and post it.

Possible messed up client using bad source IP, etc. a packet capture would validate what the source mac address is, and destination mac.. But very curious what the destination IP is.

anallama

@Gertjan It's a Sony Xperia 10 III with SailfishOS installed. So designed as an android device, but no longer running android software. Neither the phone itself or the OS are supported in Canada, but I've been hoping to find out how to get MMS working (because everything but that does work). I thought maybe something I found out from this post could eventually help. I'm not running a massive network so I don't mind a bit of extra entries in my log, though I did disable the bogon network logging eventually...

@tinfoilmatt just the classic OpenVPN port, 1194

@johnpoz to be perfectly honest, I've developed my basic understanding of computer networking and pfSense firewalling from a state of paranoia. Wasted a whole lot of mental effort and money in the process. I don't know what I should or shouldn't be hiding in posts like these beyond my public IP.

The hidden IP is one of Telus' MMS servers, 8799 is their proxy port. This traffic (25.x.x.x to Telus MMS server) shows up whenever trying to send or download an MMS message while the phone is connected to WiFi. MMS messages should be forced through cellular data all the time AFAIK, but that's obviously broken somewhere in the OS or drivers (and for clarification, the MMS service does not work when connected only via cellular data either). I can try and do a packet capture, might be up to a few days before I get around to it

Gertjan

@anallama said in Foreign source IPs from LAN from mobile device:

Neither the phone itself or the OS are supported in Canada, but I've been hoping to find out how to get MMS working (because everything but that does work)

MMS, an extension of MMS, uses operator specific the network, ports and other settings like the MMS gateway.
Your SIM card has the operator identity, the phone OS know who and what to contact to set things up.
If the phone is 'not supported', things like SMS and MMS are the first to stop working, as these need, like voice calls, a working phone / SIM / operator config.

Btw : I'm "inventing" (as I can't really remember) all this as I never actually dived into how 'SMS and MMS' works. I've read things about in in the past, when MMS needed to be setup up manually on a 310M Nokia. These were the days when we paid a small fee per SMS, and way more for MMS. Afaik, SMS and MMS doesn't use the classic (now) data or Internet traffic system of the phone, but the voice carrier (= digital also).
These days : I see them more as some 'last resort' message system.

For me, your issue starts to look like a non initialized MMS system.

@anallama said in Foreign source IPs from LAN from mobile device:

should be forced through cellular data

In the SMS/MMS age, there was no 'data' or Internet traffic as we know/use today.
Not saying that MMS can't use the data carrier.

johnpoz

@Gertjan yeah unless the carrier supports wifi calling. Which a quick google seems that telus does not. mms should be over the cell data.

I concur with a messed up stack.. How would it know to send to the local network gateway, but using some 25. address as source but sending to a local rfc1918 address would never in a million years work.

anallama

@Gertjan Well, by unsupported in these contexts, I mean: the phone was not designed for market in the Americas, so the frequency bands on the modem are not the best match (I'm always getting 1-2 bars of reception basically), and Jolla, the company that owns Sailfish OS, considers people in the Americas to be "on their own" as I understand it, despite officially supporting/maintaining the software for the Xperia 10 III specifically. So I have the community support in their forum as my only fallback. Something I see in their forum is that problems with MMS are not considered a serious issue for them because it's being phased out in Europe, or it's insecure, or something like that.

Anyhow, specifically it is only the uploading and downloading of MMS content that doesn't work. I'll still get the bubble telling me I have an MMS to download when one has been sent to me. Cellular internet, SMS, and voice calling all function normally. - And at least nowadays, MMS content gets counted against my monthly cellular data usage, and will not send or download with cellular data disabled.

I'll bring up the network stack idea at the other forum. Is a messed-up stack something that could be fixable?

anallama

I did a packet capture, should I just upload the .pcap here, and if so should I redact parts of it in some way? Or do you think it's ultimately outside the scope of this forum?

johnpoz

@anallama if its no to big you should be able to just attach to a post

anallama

@johnpoz here it is packetcapture-igc1-20260512172232.pcap

As far as I know, the IPs associated with the phone in question are 192.168.1.12 and 192.0.0.2. The 25.x.x.x addresses are not showing up on a LAN capture at least.

johnpoz

@anallama quick glance for your 8799 port shows this

That 192.0.0.2 source IP isn't going to work either. That ip is normally used for DS-Lite deployments.

Its trying to talk to a telus IP 209.202.76.198, its being sent to mac 48:21:0b:6b:87:32 which assume is pfsense mac address.. But that is never going to work, because pfsense isn't going to nat that IP range, etc.

I see 192.168.1.10 trying to talk to 8.8.8.8 443, which your getting back a RST, are you blocking that for some reason with a reject, got the answer back in .000039 seconds so highly doubt 8.8.8.8 actually sent the rst, I would guess you you have a reject rule?

But if you need to talk to 8799 - be it source of some 25 IP or 192.0.0.2 not going to work.. You could try natting that by putting an IP on pfsense in either of those ranges as secondary IP on your lan (vip) and natting it..

anallama

@johnpoz I think the phone may have changed which source IP it is using because I changed the APN settings to an alternate IPv6 setting I saw on my other telus SIM, I just forgot about it before doing this packet capture. I still don't think MMS will work with natting (however rough my understanding of that process is), as that's still an MMS server being contacted by what would end up appearing as another ISP's residential service, but I will try it in a bit.

The 192.168.1.10 is just a WAP, that has been set to use pfSense as its DNS resolver, but still was contacting 8.8.8.8 after the fact. So I blocked it, yes.

johnpoz

@anallama ok - that just jumped out at me, wouldn't/shouldn't have anything to do with it - but was curious. Yeah I hate these iot devices that think its ok to hard code dns, and not even in the clear - trying to use doh.. Little bastards ;)

JKnott

@johnpoz said in Foreign source IPs from LAN from mobile device:

Which a quick google seems that telus does not.

You didn't Google hard enough! Here's what I found:

Wi-Fi Calling for Apple and Android devices

It would be very unusual for Telus to not support WiFi calling, as it saves them having to use the cell site for the connection. I've only heard of MVNOs not having WiFi calling.

anallama

@johnpoz I switched my settings back to what they were originally when the 25 addresses were showing up. Now it's using an IP 10.16.14.157. I just do not get it.

packetcapture-igc1-20260513111243.pcap

And telus does support WiFi calling, but Sailfish OS does not.

For posterity, I'll include a link to the Sailfish OS forum thread, as I've linked this thread there.

johnpoz

@anallama yeah makes no sense, why would it not use its 192.168.1.13 address... ??

tinfoilmatt

Looks to be carrier network-destined packets simply egressing the wrong device interface. (Either that or they're leaving the right interface but destined for a tunnel that the apparently faulty 'Wi-Fi calling' logic thinks should already be established.)

johnpoz

@tinfoilmatt its leaving the same interface, that is why I searched on mac.. But yeah more than likely that should go down a tunnel that it has established, etc. Clearly it would never work like that that is for sure.

anallama

@tinfoilmatt

The 10 and 25 addresses are indeed what the cellular modem gets assigned according to netstat. Shouldn't it send the request to or through the 75 address for resolution to the MMS servers at the 209 address?

Also, interestingly enough, mobile data no longer works since I started looking into this more deeply. Was working fine before...and I haven't changed anything.