[SOLVED] Issue with Cell Phone Sending/Receiving MMS

CNLiberal

uPnP was enabled, but the gateway and LAN weren't set. I've enabled that and we'll see.

Someone on #pfsense recommended disabling the BOGON block. I can't imagine that's a good thing to do.

EDIT: No go on UPNP. The only block rules that I have are the RFC 1918 addresses and bogon. I just tried disabling those, but I have a feeling it won't matter.

kejianshi

Could also be a DNS issue I suppose… OR it could be that the messages are going out over something that doesn't like re-writing that place. Maybe you you to assign a static port in outbound NAT? But which port?

chpalmer

When is the last time you restarted the phone?

CNLiberal

Thanks for responding. I've restarted the phone a few times through this ordeal. I'll try again. As far as the ports that I need, these are the APNs that I've been using in the phone:

**NOTE: All unmentioned fields should read "<not set="">".

APN 1 (Up to 3.5G HSDPA/HSUPA only, 7.2mbps):
Name: Cingular
APN: wap.cingular
Proxy: wireless.cingular.com
Port: 80
MMS protocol: WAP 2.0
MCC: 310
MNC: 410
APN type: default,agps,supl,fota,dun

APN 2 (Up to 3.75G HSPA+ only, 21mbps):
Name: AT&T HSPA+
APN: phone
MMS protocol: WAP 2.0
MCC: 310
MNC: 410
APN type: default,agps,supl,dun

APN 3 (LTE, ALL THE mbps):
Name: AT&T LTE
APN: pta
MMS protocol: WAP 2.0
MCC: 310
MNC: 410
APN type: default,agps,supl,hipri,internet

APN 4:
Name: Cingular MMS
APN: wap.cingular
Proxy: wireless.cingular.com
Port: 80
MMSC: http://mmsc.cingular.com
MMS proxy: wireless.cingular.com
MMS port: 80
MMS protocol: WAP 2.0
MCC: 310
MNC: 410
APN type: mms

APN 5:
Name: AT&T LTE MMS
APN: pta
MMSC: http://mmsc.mobile.att.net
MMS proxy: proxy.mobile.att.net
MMS port: 80
MMS protocol: WAP 2.0
MCC: 310
MNC: 410
APN type: hipri,mms</not>

From what I can see, I just need port 80 open outbound, which is already open as I am pretty sure I have no ports blocked outgoing.

CNLiberal

OK, I'm in FIREWALL:RULES. Choosing the WAN side, this is basically the setup:

```
Protocol Source Port Destination Port Gateway Queue

 IPv4 TCP	 *	 *	MediaServer_Int	 9090	 *	 none


This is the same for all the open ports I have.  There are _no_ blocks listed on that tab.

On the LAN tab:

ID Proto Source Port Destination Port Gateway Queue Schedule
* * * LAN Address 443,80,22 * *
IPv4 * * * * * * none


Those are my rules.  I can't see anywhere that this is being blocked.  I'm not even blocking Bogon networks at this point.

georgeman

+1 to the outbound NAT static ports. Some services do not like to have their ports rewritten, and that is something that most likely "all your friends' firewall" cannot and don't do.

kejianshi

Well - It doesn't have to be blocked to be broken. Static ports are assigned under NAT > Manual outbound (vs automatic)

I'm not sure if it will help to assign static to whichever port your phone needs (port 80 or 443 perhaps) but it might.

The only time I have to do that is with port 5060 UDP for my sip server.

georgeman

LogMeIn Hamachi also needs UDP ports to be static for it work properly

CNLiberal

I have finally solved the issue. I'm so happy it's fixed. For those that happen upon this thread, here's what I did:

Since I had nothing blocked in the firewall rules, and I had Outbound Manual NAT enabled that wasn't the issue. I was in the #pfsense channel, and someone happened to come in complaining about not a ping not resolving. Specifically, he was trying to ping:

ping some_DNS_name_on_internet

It was supposed to resolve to a PRIVATE IP address, in his case, 10.0.0.1. I could get it to resolve from my work connection (not behind pfSense). So I began pinging the MMSC and MMS addresses in the APNs I listed earlier. All of them resolved and/or responded, except one:

proxy.mobile.att.net

Behind the pfSense 2.1 firewall, it wouldn't resolve. From anywhere else (from the phone disconnected from WiFi, from my office network) that address would resolve:

$ ping proxy.mobile.att.net
PING proxy.mobile.att.net (172.26.39.1) 56(84) bytes of data.
^C
--- proxy.mobile.att.net ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

But look at the address it was resolving to! I thought that since I had disabled blocking RFC1918 on my WAN port and LAN port, the address would have resolved. It didn't. The user in #pfsense said that it's not a bug, but a feature of dnsmasq and that pfSense was "protecting us from ourselves". Very strange I thought. But what's even stranger, was the fact that AT&T was deliberately resolving a DNS name to an RFC 1918 address on the PUBLIC internet. My only guess is that the phone will try the WiFi first, find that this address resolves to 172.26.39.1 address, then use it's LTE radio to connect to the address since it's all on AT&T's network anyway. Probably a static route on the LTE radio? No idea.

Since it was clear that pfSense wasn't resolving this address correctly, I decided to put a "Host Over Ride" in the Services: DNS Forwarder. I added this:

proxy 	 mobile.att.net 	 172.26.39.1 	 AT&T MMS Proxy

Once I did that, everything worked as expected. She can send and receive MMS. It was amazing. I've been struggling with this for a week, and now it's working. That also means I can go buy me the same phone :-)

I really hope that my struggles can help someone in the future.

kejianshi

172.26.39.1 ???

Someone at ATT is on crack…

If you have registered your domain name lately, or if you move it from one provider to another, here you can check if the name www.yourdomain.com already is know by the world and if it works correctly.
Type in your domain name (like www.yourdomain.com) here and press the button, to see the results.
Resolution of proxy.mobile.att.net is 172.26.39.1

You are right - They hijacked a private space. haha.

I've seen people on this forum hijack public space, but I've not seen a behemoth like ATT be that dumb before.
For me, its a first. Never would have figured it out.

razzfazz

An alternative solution is to check "disable DNS rebinding checks" in system -> advanced.

CNLiberal

@kejianshi:

172.26.39.1 ???

Someone at ATT is on crack…

If you have registered your domain name lately, or if you move it from one provider to another, here you can check if the name www.yourdomain.com already is know by the world and if it works correctly.
Type in your domain name (like www.yourdomain.com) here and press the button, to see the results.
Resolution of proxy.mobile.att.net is 172.26.39.1

You are right - They hijacked a private space. haha.

I've seen people on this forum hijack public space, but I've not seen a behemoth like ATT be that dumb before.
For me, its a first. Never would have figured it out.

Thanks for sticking with me during this extremely odd situation. You were the only one giving me good feedback during this ordeal. Luckily, that guy happened to pop into #pfsense at the same time I was there and reported the same issue.

kejianshi

Well - Of course the best fix for this has nothing to do with pfsense.
The best fix would be for ATT to get an IP for their proxy in the public range.

Maybe give them a call and tell them what you think?