Does AT&T change IP addresses for ios devices?
December 10, 2014 12:22 PM Subscribe
My IP address on my iDevice (iPhone & iPad) shows one thing when I go to "whatismyip.com", but my email server shows something different. What is going on?
I'm trying to diagnose errors setting up IMAP accounts on ios devices. Curiously when I set up an account on an iPad or iPhone, connected via LTE, WiFi shut OFF, I get an address of
107.77.68.23 reported at any of the "whatismyip... .com" sites.
On my email server at work I see this:
13:54:41.677 5 SMTP [0.0.0.0]:587 <- [166.172.59.227]:29528 connection request. socket=227
13:54:41.677 5 SMTP new VStream created, 3 total
13:54:41.691 5 SMTP stream thread started
13:54:41.691 4 SMTPI-002021([166.172.59.227]) [192.168.200.100]:587 <- [166.172.59.227]:29528 incoming connection
The 107.77.68.23 stays consistent, even after I try to set up the account, as does the 166.172.59.227. I can reload the 'whatismyip.com' page over & over and get the same 107.77.68.23 address. The addresss reported in my email server logs are always 166.172.59.227. The only time the addresses change is if I put the phone in airplane mode and then back off. However, the new addresses, while not the same as the previous ones, still do not match from phone to server.
If I set up an iPhone (ios 7) , I get an address on LTE network of 107.77.68.28 but my email server reports 166.172.58.84:
13:32:58.872 5 SMTP [0.0.0.0]:587 <- [166.172.58.243]:36163 connection request. socket=208
13:32:58.873 4 SMTPI-001944([166.172.58.243]) [192.168.200.100]:587 <- [166.172.58.243]:36163 incoming connection
What is going on?!
I'm trying to diagnose errors setting up IMAP accounts on ios devices. Curiously when I set up an account on an iPad or iPhone, connected via LTE, WiFi shut OFF, I get an address of
107.77.68.23 reported at any of the "whatismyip... .com" sites.
On my email server at work I see this:
13:54:41.677 5 SMTP [0.0.0.0]:587 <- [166.172.59.227]:29528 connection request. socket=227
13:54:41.677 5 SMTP new VStream created, 3 total
13:54:41.691 5 SMTP stream thread started
13:54:41.691 4 SMTPI-002021([166.172.59.227]) [192.168.200.100]:587 <- [166.172.59.227]:29528 incoming connection
The 107.77.68.23 stays consistent, even after I try to set up the account, as does the 166.172.59.227. I can reload the 'whatismyip.com' page over & over and get the same 107.77.68.23 address. The addresss reported in my email server logs are always 166.172.59.227. The only time the addresses change is if I put the phone in airplane mode and then back off. However, the new addresses, while not the same as the previous ones, still do not match from phone to server.
If I set up an iPhone (ios 7) , I get an address on LTE network of 107.77.68.28 but my email server reports 166.172.58.84:
13:32:58.872 5 SMTP [0.0.0.0]:587 <- [166.172.58.243]:36163 connection request. socket=208
13:32:58.873 4 SMTPI-001944([166.172.58.243]) [192.168.200.100]:587 <- [166.172.58.243]:36163 incoming connection
What is going on?!
The 166.172 addresses' reverse lookup says they're mobile-*.mycingular.net, so that's AT&T. However these connections are not IMAP, they're SMTP.
Most likely they are proxying SMTP traffic, probably analyzing it for spamminess on the way out. Send yourself a test message, and check its headers to see if they say anything about this.
It's probable that the actual IMAP logs will report the same IP as whatismyip.com.
posted by aubilenon at 12:50 PM on December 10, 2014
Most likely they are proxying SMTP traffic, probably analyzing it for spamminess on the way out. Send yourself a test message, and check its headers to see if they say anything about this.
It's probable that the actual IMAP logs will report the same IP as whatismyip.com.
posted by aubilenon at 12:50 PM on December 10, 2014
Response by poster: Yes I know they aren't IMAP. I'm trying to diagnose why I can't get IMAP accounts to work vs. why selecting Exchange as the email account type does work. One resolution from our email provider is to whitelist the IP address of the phone during the initial setup, which turns out to be very difficult with AT&T for the varying IP addresses.
posted by dukes909 at 12:54 PM on December 10, 2014
posted by dukes909 at 12:54 PM on December 10, 2014
It definitely looks like they are proxying port 587 traffic. What encryption / authentication are you using?
If you have the option, I would switch to SMTP with TLS/SSL on port 465, which at least in most clients will force SSL handshaking before the SMTP connection opens (i.e. not the silly STARTTLS stuff), and should throw some sort of SSL error if they still try to force it through their proxy.
You could also try to connect to the SMTP server using Telnet from both places, and see if the banner and other connection information you get both ways is the same. That might be interesting.
posted by Kadin2048 at 12:58 PM on December 10, 2014 [1 favorite]
If you have the option, I would switch to SMTP with TLS/SSL on port 465, which at least in most clients will force SSL handshaking before the SMTP connection opens (i.e. not the silly STARTTLS stuff), and should throw some sort of SSL error if they still try to force it through their proxy.
You could also try to connect to the SMTP server using Telnet from both places, and see if the banner and other connection information you get both ways is the same. That might be interesting.
posted by Kadin2048 at 12:58 PM on December 10, 2014 [1 favorite]
Response by poster: Can I do telnet from an iPhone?
Yes I do have 465 set up on the server with SSL. However, there is no option on the iPhone/iPad to specify to use 465 SSL in the inital setup - only once the account is already added and working.
posted by dukes909 at 1:02 PM on December 10, 2014
Yes I do have 465 set up on the server with SSL. However, there is no option on the iPhone/iPad to specify to use 465 SSL in the inital setup - only once the account is already added and working.
posted by dukes909 at 1:02 PM on December 10, 2014
I'm not sure if this will be helpful to you, but here's some information on what I think is happening and why you're getting different IP addresses reported from different servers.
If you're connected via the cellular network (3G/4G/LTE), you will be assigned an IP address when you first connect to a cell tower. If you're moving and are therefore handed off to another cell tower, you'll get a new IP address. The connection is kept active when moving between towers using GTP so that you appear to have the same IP address throughout (apparently 166.172.59.227 for this first connection session you listed, and 166.172.58.84 for the second session). If you put your phone in airplane mode, you're disconnecting from the LTE network, and so you'll get a new IP address assigned when you reconnect to LTE (take it out of airplane mode). It looks like these IP addresses are consistently in the 166.172.xxx.xxx block.
IP addresses in the 192.168.xxx.xxx (last line of your first set of SMTP logs) are private IP addresses, which might be assigned to your device by your WiFi router, or assigned to your connection by your cellular provider if you're going through a proxy.
107.77.68.23 maps to a Static IP AT&T Wireless in Tennessee. A similar reverse lookup of 166.172.59.227 shows that it is a Dynamic IP address for AT&T Wireless. 107.77.68.23 is likely the point where AT&T connects their cell tower network in your area to their Internet backbone. Same with 107.77.68.28. It's highly possible that you're trying to connect to the LTE network from an area where you can clearly communicate with at least two cell towers, and you get the IP of whichever one you happen to connect to first.
This all should not matter, as IMAP in theory should allow connections from anywhere on port 143, and does allow for multiple simultaneous connections to the same mailbox. SMTP, being a send-only protocol, should also allow connections from anywhere. In fact, I'm not certain why you're having issues as long as the IMAP and SMTP server connection information for your email provider is correct.
posted by tckma at 2:02 PM on December 10, 2014
If you're connected via the cellular network (3G/4G/LTE), you will be assigned an IP address when you first connect to a cell tower. If you're moving and are therefore handed off to another cell tower, you'll get a new IP address. The connection is kept active when moving between towers using GTP so that you appear to have the same IP address throughout (apparently 166.172.59.227 for this first connection session you listed, and 166.172.58.84 for the second session). If you put your phone in airplane mode, you're disconnecting from the LTE network, and so you'll get a new IP address assigned when you reconnect to LTE (take it out of airplane mode). It looks like these IP addresses are consistently in the 166.172.xxx.xxx block.
IP addresses in the 192.168.xxx.xxx (last line of your first set of SMTP logs) are private IP addresses, which might be assigned to your device by your WiFi router, or assigned to your connection by your cellular provider if you're going through a proxy.
107.77.68.23 maps to a Static IP AT&T Wireless in Tennessee. A similar reverse lookup of 166.172.59.227 shows that it is a Dynamic IP address for AT&T Wireless. 107.77.68.23 is likely the point where AT&T connects their cell tower network in your area to their Internet backbone. Same with 107.77.68.28. It's highly possible that you're trying to connect to the LTE network from an area where you can clearly communicate with at least two cell towers, and you get the IP of whichever one you happen to connect to first.
This all should not matter, as IMAP in theory should allow connections from anywhere on port 143, and does allow for multiple simultaneous connections to the same mailbox. SMTP, being a send-only protocol, should also allow connections from anywhere. In fact, I'm not certain why you're having issues as long as the IMAP and SMTP server connection information for your email provider is correct.
posted by tckma at 2:02 PM on December 10, 2014
Response by poster: Thanks, I'm not moving when I'm checking the logs..just sitting in my office. The address remains constant, as I said, provided I don't toggle Airplane mode. The 192.168.200.100 address is the address of the email server NAT'd sitting behind the firewall; it's not related to this issue.
That being said the static addresses of the wireless (towers?) makes sense - thanks for that.
I know the IMAP & SMTP should not matter about the addresses. In fact, it works perfectly for IMAP/SMTP mail on a Mac, PC's, and Linux boxes. It also works on the one Android device that I have access to test with. The errors only occur with iOS devices, and there is usually a string of gibberish that is sent in the initial transaction that I have yet to understand (the 69.197.xxx.xx) is an address assigned to an iOS device when I was testing it another time:
10:06:40.688 4 SMTPI-011473([69.197.220.11]) [192.168.200.100]:587 <> 10:06:40.688 5 SMTPI-011473([69.197.220.11]) out: 220 ourdomain.net ESMTP CommuniGate Pro 6.0.10\r\n
10:06:40.691 5 SMTPI-011473([69.197.220.11]) inp: \022\003\001
10:06:42.693 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:42.693 5 SMTPI-011473([69.197.220.11]) inp: \163\001
10:06:44.696 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:44.696 5 SMTPI-011473([69.197.220.11]) inp:
10:06:46.698 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:46.698 5 SMTPI-011473([69.197.220.11]) inp: \159\003\001T\135 l
10:06:48.700 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:48.700 5 SMTPI-011473([69.197.220.11]) inp: \004\225\176d2\217\180\005"]\167\176\182\131N&\183\175\218\167\200\167\245\003\246\005\221
10:06:50.702 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:50.702 1 SMTPI-011473([69.197.220.11]) Too many protocol errors, aborting
10:06:50.723 4 SMTPI-011473([69.197.220.11]) closing connection
10:06:50.723 4 SMTPI-011473([69.197.220.11]) releasing stream
posted by dukes909 at 3:26 PM on December 10, 2014
That being said the static addresses of the wireless (towers?) makes sense - thanks for that.
I know the IMAP & SMTP should not matter about the addresses. In fact, it works perfectly for IMAP/SMTP mail on a Mac, PC's, and Linux boxes. It also works on the one Android device that I have access to test with. The errors only occur with iOS devices, and there is usually a string of gibberish that is sent in the initial transaction that I have yet to understand (the 69.197.xxx.xx) is an address assigned to an iOS device when I was testing it another time:
10:06:40.688 4 SMTPI-011473([69.197.220.11]) [192.168.200.100]:587 <> 10:06:40.688 5 SMTPI-011473([69.197.220.11]) out: 220 ourdomain.net ESMTP CommuniGate Pro 6.0.10\r\n
10:06:40.691 5 SMTPI-011473([69.197.220.11]) inp: \022\003\001
10:06:42.693 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:42.693 5 SMTPI-011473([69.197.220.11]) inp: \163\001
10:06:44.696 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:44.696 5 SMTPI-011473([69.197.220.11]) inp:
10:06:46.698 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:46.698 5 SMTPI-011473([69.197.220.11]) inp: \159\003\001T\135 l
10:06:48.700 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:48.700 5 SMTPI-011473([69.197.220.11]) inp: \004\225\176d2\217\180\005"]\167\176\182\131N&\183\175\218\167\200\167\245\003\246\005\221
10:06:50.702 5 SMTPI-011473([69.197.220.11]) out: 501 Unknown command\r\n
10:06:50.702 1 SMTPI-011473([69.197.220.11]) Too many protocol errors, aborting
10:06:50.723 4 SMTPI-011473([69.197.220.11]) closing connection
10:06:50.723 4 SMTPI-011473([69.197.220.11]) releasing stream
posted by dukes909 at 3:26 PM on December 10, 2014
The only thing that would make sense to have binary crap there would be a TLS handshake but as far as I can tell the first two bytes of that should always be the protocol version which would be \003\003 or similar.
I very much doubt AT&T is doing this, but you can cut them out of the picture entirely by connecting through wifi.
posted by aubilenon at 3:48 PM on December 11, 2014
I very much doubt AT&T is doing this, but you can cut them out of the picture entirely by connecting through wifi.
posted by aubilenon at 3:48 PM on December 11, 2014
Sorry for the late reply, but I found this by Google while investigating a similar issue. In my case the problem is I run a video service, and our iOS client on certain carriers (AT&T is one of them) is sending API requests to our server from one IP, and sending video asset requests to our CDN from a different IP. The former is under HTTPS, but the latter under HTTP, so presumably they are doing some HTTP proxying shenanigans as well.
BTW, the same symptom is exhibiting heavily in Mexico and many other countries I operate in as well, so this looks like par for the course.
posted by dasil003 at 6:14 PM on January 28, 2015
BTW, the same symptom is exhibiting heavily in Mexico and many other countries I operate in as well, so this looks like par for the course.
posted by dasil003 at 6:14 PM on January 28, 2015
« Older Is This A Phone Scam? My Health Insurance Company... | My graduate program is a disappointment. Now what? Newer »
This thread is closed to new comments.
posted by Oktober at 12:42 PM on December 10, 2014