Archived and Closed
This conversation is no longer open for comments or replies and is no longer visible to community members.
I have an ATT 3G MicroCell which has been working perfectly for about 24 months. On Wed, 2/18/15, it lost its ability to communicate with the internet. After much searching, it was determined that the 4 ports required for its functionality are now blocked. How does one go about opening those ports?
Posted 3 years ago
The number I provided is not for our front-line Technical Support, but our Technical Escalations department. Please give them a call for port assistance.
Since we can't get through to that department, can you please forward them the following requirements that will allow the Microcell to function again. Thanks.
Procedure
Procedure
NOTE: Please be advised that the router manufacture or the ISP provider will not provide support for AT&T Microcell, but they can assist with configuring the router settings.
- DHCP is on
- Data is not restricted from passing through ports 4500 and 500 (AKA Port Blocking).
- MTU size is set to 1492
- MAC address filtering is either turned off or allowing the MAC address of the AT&T Microcell
- IPSec Pass-Through is Enabled
- Block Fragmented Packets is Disabled
- If using multiple routers, the Microcell must be connected to the first router connected to the broadband modem
- If the Microcell is connected to a router that is connected to a modem and both the router and the modem have NAT (Network Address Translation) enabled, disable NAT either in the router or the modem.
- Ensure the modem / router is using the latest software (firmware). Please see the manufacturer's documentation.
-
TCP/UDP Ports
NOTE: All ports listed need to be configured for inbound and outbound connections. - 123/UDP: NTP timing (NTP traffic)
- 443/TCP: Https over TLS/SSL for provisioning and management traffic
- 4500/UDP: IPSec NAT Traversal (for all signaling, data, voice traffic)
- 500/UDP: IPSec Phase 1 prior to NAT detection (after NAT detection, 4500/UDP is used)
- 4500/UDP: After NAT detection, 4500/UDP is used
I can confirm (by testing) that these ports are in fact open (in the general sense, unless they are blocked for specific IP addresses):
-
TCP/UDP Ports
NOTE: All ports listed need to be configured for inbound and outbound connections. - 123/UDP: NTP timing (NTP traffic)
- 443/TCP: Https over TLS/SSL for provisioning and management traffic
- 4500/UDP: IPSec NAT Traversal (for all signaling, data, voice traffic)
- 500/UDP: IPSec Phase 1 prior to NAT detection (after NAT detection, 4500/UDP is used)
- 4500/UDP: After NAT detection, 4500/UDP is used
I have tried that number 3 times, and after the automated dialog said hold for the next available... it disconnects after 10 seconds.
still disconnecting, I guess they aren't really that interested in hearing about problems
Brand new uint has the same problems. If you think about it, this is a simple product - a radio and an IPSec tunnel into the ATT network. I will get on the ATT side of things to find out where this tunnel is supposed to go, and see if we can reconnect. Thanks for your help, I'll keep in touch.
Packet capture shows:
172.26.241.1:29169 (sctp) [this is private address space, so I'm not sure why it's hitting my network, perhaps because the tunnel endpoint is not established so it's following the default route]
12.230.209.137:443 (https)
12.230.209.133:123 (ntp)
12.230.208.133:123 (ntp)
12.230.209.5:123 (ntp)
12.230.209.134:4500 (ipsec NAT traversal)
12.230.209.134:500 (isakmp)
It also does misc ARP requests to announce itself on the network, but that's not relevant.
I verified that all three NTP servers are responding appropriately. At least in my case the AT&T rep indicated it was an IKE authentication failure. I can see that attempted over and over, but can't really tell what's it's doing (ports 500/4500):
09:48:27.680056 IP 192.168.1.249.isakmp > 12.230.209.134.isakmp: isakmp: parent_sa ikev2_init[I]
09:48:28.423738 IP 192.168.1.249.4500 > 12.230.209.134.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
09:48:28.423804 IP 192.168.1.249 > 12.230.209.134: udp
09:48:38.390248 IP 192.168.1.249.4500 > 12.230.209.134.4500: isakmp-nat-keep-alive
09:48:38.425314 IP 192.168.1.249.4500 > 12.230.209.134.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
09:48:38.425358 IP 192.168.1.249 > 12.230.209.134: udp
Anyway, maybe that's useful info.......
172.26.241.1:29169 (sctp) [this is private address space, so I'm not sure why it's hitting my network, perhaps because the tunnel endpoint is not established so it's following the default route]
12.230.209.137:443 (https)
12.230.209.133:123 (ntp)
12.230.208.133:123 (ntp)
12.230.209.5:123 (ntp)
12.230.209.134:4500 (ipsec NAT traversal)
12.230.209.134:500 (isakmp)
It also does misc ARP requests to announce itself on the network, but that's not relevant.
I verified that all three NTP servers are responding appropriately. At least in my case the AT&T rep indicated it was an IKE authentication failure. I can see that attempted over and over, but can't really tell what's it's doing (ports 500/4500):
09:48:27.680056 IP 192.168.1.249.isakmp > 12.230.209.134.isakmp: isakmp: parent_sa ikev2_init[I]
09:48:28.423738 IP 192.168.1.249.4500 > 12.230.209.134.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
09:48:28.423804 IP 192.168.1.249 > 12.230.209.134: udp
09:48:38.390248 IP 192.168.1.249.4500 > 12.230.209.134.4500: isakmp-nat-keep-alive
09:48:38.425314 IP 192.168.1.249.4500 > 12.230.209.134.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
09:48:38.425358 IP 192.168.1.249 > 12.230.209.134: udp
Anyway, maybe that's useful info.......
I brought the old unit into my office and authorized it on a T1 based network. It worked perfectly, and the whole process took just a few minutes. I have another Exede feed in this building, and I will try to get it tomorrow. Seems like an Exede problem, not ATT.
If you do a search on 12.230.209.134 one finds similar problems, dating back to 2003, on different equipment and different networks. The general consensus is that the problem has something to do with fragmented packets and the way they are handled. Hopefully someone, either ATT or ViaSat can adjust the settings. There are several suggestions in some of the more technical posts out there.
Your internal firewall you are using to access Viasaat may be blocking ICMP traffic, so don't assume that just because you cannot do a traceroute that the IP is blocked. Can you traceroute successfully to other IP addresses and get full results?
yes
It won't trace because it's part of RFC1918 address space. I guess the real question is why a microcell would be trying to contact any server on this address space. Perhaps it's because the microcell creates a tunnel and this is the endpoint.
Dog gone it. I must be tired, Johnson Family gets geek of the week award for catching the fact it is a private IP address (RFC1918) and hence the reason it is not reachable. Good catch. Hopefully they will get you straight with this.
I know with dealing with Verizon and Comcast both, they will put blocks in their systems that we have had to go to Level 3 techs to get information. Clients are yelling at us because something that worked yesterday doesn't work today and it was the ISP changing something that most of their front line support folks didn't know about.
Good luck.
I posted the ATT solution stuff above. The tech said that there is no built in ip addressing, so that address must be left over from something else. He suggested a hard reset (the little button) which I had already done several times. We shall see if a new unit does the job.
I just setup a connection to my work network using the Shrewsoft VPN client to a hardware VPN firewall and it connected and worked just fine. The internal network addresses are in the 10.X range so they are in the 10/8 RFC 1918 network and I can work and ping just fine. The ports used from the client to the hardware device are 500 and 4500 so it would appear at least those two ports are allowed through my Exede connection.
I did something similar myself. I have a dual WAN Cisco router at work, and the second WAN on it is a different Exude feed. When I get back on Tuesday, I will try connecting through that, as the primary WAN connection through the T1 worked just fine. I will also do a packet capture like Johnson above. Has anyone spoken to Exude tech support lately?
I sent the following email to exedelistens@viasat.com referencing this thread
There is a great deal of technical detail in the thread. It seems as if the ports are open, but the key exchange to open the tunnel is failing. There are at least 6 others in the same position who are posting, and it seems this also happened in 2013. Link to the old post is:
Perhaps if other do the same, we can get this escalated as there is clearly nothing we as end users can do to fix this problem.
There is a great deal of technical detail in the thread. It seems as if the ports are open, but the key exchange to open the tunnel is failing. There are at least 6 others in the same position who are posting, and it seems this also happened in 2013. Link to the old post is:
http://www.wildblueworld.com/forum/archive/index.php/t-7067.html
My contact information is below. Please advise and post if possible. There are a lot of angry customers, especially over the silence.Perhaps if other do the same, we can get this escalated as there is clearly nothing we as end users can do to fix this problem.
actually they aren't being silent. If you look over on the old wildblueworld forums, one of the exede engineers is talking directly to a couple of at&t customers, getting their info (in private message) trying to work out the issue. He stated that exede actually purchased MicroCell units, and are trying to work out the issue. Personally, to me, that's far above and beyond what most companies would do. Most would simply tell you that they can't guarantee any third party product will work, sorry.
I was hoping for a post in this forum, as one of the Exede employees replied once.
Here in Rural California, with the same problems as outlined still no resolve.
Any further info? I am having the same problem, and still have not heard anything anywhere where this has been solved.
ExedeNeil, Official Rep
Hi All. I have been looking at the ATT microcell issue for a few weeks now. If you get a chance, please see the thread at https://www.wildblueworld.com/forum/showthread.php?8836-ATT-Microcell
Several customers had similar issues and for some of them, things started working in the past two weeks.
My diagnosis so far is that the handshake between the Microcell and the ATT servers works with certain ATT servers, but not with others. There seems to be an issue with IPSec key exchange handshakes and packets larger than 1500 bytes sent by some servers, which the microcell probably rejects.
If you can send me your account number or the modem MAC address by private email on the wildblue forum (this forum does not seem to have a private email facility), I can inspect your modems and see if your modem has similar symptoms.
Of course, you have to make sure that you have opened ports 500 and 4500 on the router, as described in the ATT microcell web site http://www.att.com/esupport/article.jsp?sid=KB110286&cv=820. Exede does not block these ports.
We are looking into various options on how we can make this work. Will keep you posted as we make progress. Meanwhile, restarting the microcell may help, if it manages to hook up with a different ATT server.
ExedeNeil
Several customers had similar issues and for some of them, things started working in the past two weeks.
My diagnosis so far is that the handshake between the Microcell and the ATT servers works with certain ATT servers, but not with others. There seems to be an issue with IPSec key exchange handshakes and packets larger than 1500 bytes sent by some servers, which the microcell probably rejects.
If you can send me your account number or the modem MAC address by private email on the wildblue forum (this forum does not seem to have a private email facility), I can inspect your modems and see if your modem has similar symptoms.
Of course, you have to make sure that you have opened ports 500 and 4500 on the router, as described in the ATT microcell web site http://www.att.com/esupport/article.jsp?sid=KB110286&cv=820. Exede does not block these ports.
We are looking into various options on how we can make this work. Will keep you posted as we make progress. Meanwhile, restarting the microcell may help, if it manages to hook up with a different ATT server.
ExedeNeil
I have registered for the other forum, but I don't see your address to send a private email. Please provide an email address or link so I can send you the info. Thanks!
Click on his name and the option for Private Message shows up
https://www.wildblueworld.com/forum/showthread.php?8836-ATT-Microcell/page8
https://www.wildblueworld.com/forum/showthread.php?8836-ATT-Microcell/page8
Thanks. Got it!