We believe ATT is blocking ISAKMP (port 500) traffic somewhere on their mobile network. Using a laptop with a CSpire phone as a MIFI hotspot, Sonicwall VPN software works flawlessly. Same system using an ATT phone as a MIFI hotspot throws up ISAKMP errors - the same error one would get if there was a break in the wireless path. In troubleshooting (simpler) routing issues in the past, I was able to TRACERT to a specific IP address and it was clear where the traffic was blocked. We sent the IP address of the offending router to Comcast and they fixed the issue. Could someone recommend a method to see where along the route the ISAKMP traffic is being blocked? Thanks. asked 26 Mar '15, 16:50 matrixmike |
3 Answers:
send IKE frames with increasing IP TTL and test where you don't get "ICMP time exceeded" answers anymore, if they send them at all. Scapy is a good tool to send those frames: Regards answered 26 Mar '15, 18:21 Kurt Knochner ♦ |
It's more likely to be some kind of MTU issue rather than operator actively blocking packets. You can try forcing your laptop to use smaller MTU size answered 27 Mar '15, 02:21 izopizo |
I've used lft to troubleshoot an identical issue with another ISP in the past as it can use tcp or udp as the bearer protocol for testing rather than icmp as in standard traceroute. Unfortunately lft isn't available for Windows. lft was needed because in our issue the ISP had an egress filter on a router that blocked udp port 500 but allowed icmp to pass through, thus traceroute worked but lft showed where the block was. answered 27 Mar '15, 03:15 grahamb ♦ |