[SOLVED] Issue with Cell Phone Sending/Receiving MMS



  • I've been dealing with this issue on my wife's Google Edition Galaxy S4.  When she's on our WiFi network, she is unable to send or receive MMS messages.  When she's on anyone else's network, sending and receiving is no problem.  When I remove her from our WiFi network (the phone is still in the apartment) she is able to send and receive just fine.  I tried swapping out our AP from an old WRT-54G to an Asus RT-AC66U running in AP mode.  Still nothing.  What's crazy is that if I take my pfSense box out of the mix, and use the Asus as the router/firewall/AP, MMS works perfectly.  No issues.

    I am on pfSense 2.1.  I had a couple items in the rules/nat, but nothing extreme.  So I decided to save my config, and factory reset.  Plain jane vanilla install, and the same issue.  I even tried changing my IP address to see if it was an issue with overlapping IP ranges (I ususally run a 10.0.0.0/24 so I tried a 192.168.1.1/24), no go.

    I've ran several packet captures, but I can't see anything getting blocked.  This is getting super frustrating.  At the suggestion of #pfsense, I added a 1:1 NAT rule:

    WAN	My_Ext_IP	192.168.1.103	*
    

    This didn't solve the issue either.  I'm really at my wits end.  There's no way I want to give up pfSense, but I have to make this work.  Any help would be greatly appreciated.  Thanks!



  • Running dansguardian or anything like that?



  • Thanks for replying!  The only packages I'm running are:

    bandwidthd
    Cron
    OpenVPN Client Export
    RRD Summary

    Also, at the time, I ran a bone stock version of pfSense.



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


  • +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_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.



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



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



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



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


Log in to reply