[SOLVED] Issue with Cell Phone Sending/Receiving MMS
-
In that case, I don't see anything that would mess up MMS. I was thinking that possibly some squid issue or something, but you are running a very vanilla pfsense, so I don't know. Could it be just a problem with the phone its self?
-
When the phone is connected to any other WiFi network (or not connected to any WiFi network) it can send just fine. It's only on pfSense that it won't send.
-
Do you have some rules set up on the WAN or LAN that would prevent it? Does it need uPNP turned on?
-
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.
-
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?
-
When is the last time you restarted the phone?
-
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.
-
OK, I'm in FIREWALL:RULES. Choosing the WAN side, this is basically the setup:
```
Protocol Source Port Destination Port Gateway QueueIPv4 TCP * * MediaServer_Int 9090 * noneThis 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 * * * * * * noneThose are my rules. I can't see anywhere that this is being blocked. I'm not even blocking Bogon networks at this point. -
+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.
-
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.
-
LogMeIn Hamachi also needs UDP ports to be static for it work properly
-
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_internetIt 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 1007msBut 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 ProxyOnce 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.
-
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.1You 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. -
An alternative solution is to check "disable DNS rebinding checks" in system -> advanced.
-
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.1You 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.
-
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?
