T-Mobile CellSpot not working

A Former User

I just installed a T-Mobile 4G LTE CellSpot (residential femtocell) on my LAN and it is failing to establish a connection back to T-Mobile. I just got this device because I couldn’t get Wi-Fi calling to work on my phones (I think for the same reason).

My setup: Windows 2012 R2 running pfSense 2.4.3 (FreeBSD 11.1) under Hyper-V. I’m using an Intel PRO/1000 PT Quad Port LP Server Adapter NIC with offloading disabled in both Windows and pfSense. I’ve got Verizon Fios/business and pfSense mostly running default settings besides pfBlockerNG (disabled right now). “Disable Firewall Scrub” is enabled but it doesn’t seem to help.

After more than 20 hours of reading online and trying every settings combination, I can’t figure this out. Unfortunately networking isn’t my strong point. Can someone offer some advice? It looks like a lot of people have similar problems but the solutions escape me.

It looks like my CellSpot (192.168.0.234) device is sending an IPSEC request on port 4500 but it’s getting fragmented and the T-Mobile side (208.54.66.193) never responds.

Relevant part of the tcp dump from the LAN side:

22:09:18.637001 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 1514: (tos 0xb8, ttl 64, id 38030, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.0.234.4500 > 208.54.66.193.4500: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 60b59b71ae4adda2->d2623db09864ab8f: child_sa  ikev2_auth[I]: [|v2e] (len mismatch: isakmp 2108/ip 1468)
22:09:18.637024 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 674: (tos 0xb8, ttl 64, id 38030, offset 1480, flags [none], proto UDP (17), length 660)
    192.168.0.234 > 208.54.66.193: ip-proto-17
22:09:22.637200 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 1514: (tos 0xb8, ttl 64, id 38031, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.0.234.4500 > 208.54.66.193.4500: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 60b59b71ae4adda2->d2623db09864ab8f: child_sa  ikev2_auth[I]: [|v2e] (len mismatch: isakmp 2108/ip 1468)
22:09:22.637220 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 674: (tos 0xb8, ttl 64, id 38031, offset 1480, flags [none], proto UDP (17), length 660)
    192.168.0.234 > 208.54.66.193: ip-proto-17
22:09:29.837370 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 1514: (tos 0xb8, ttl 64, id 38032, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.0.234.4500 > 208.54.66.193.4500: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 60b59b71ae4adda2->d2623db09864ab8f: child_sa  ikev2_auth[I]: [|v2e] (len mismatch: isakmp 2108/ip 1468)
22:09:29.837396 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 674: (tos 0xb8, ttl 64, id 38032, offset 1480, flags [none], proto UDP (17), length 660)
    192.168.0.234 > 208.54.66.193: ip-proto-17
22:09:42.797343 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 1410: (tos 0xb8, ttl 64, id 38033, offset 0, flags [+], proto UDP (17), length 1396)
    192.168.0.234.4500 > 208.54.66.193.4500: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 60b59b71ae4adda2->d2623db09864ab8f: child_sa  ikev2_auth[I]: [|v2e] (len mismatch: isakmp 2108/ip 1364)
22:09:42.797364 a0:64:8f:fb:5f:0a > 00:15:5d:00:c8:0b, ethertype IPv4 (0x0800), length 778: (tos 0xb8, ttl 64, id 38033, offset 1376, flags [none], proto UDP (17), length 764)
    192.168.0.234 > 208.54.66.193: ip-proto-17

Relevant part of the tcp dump from the WAN side (from another attempt):

22:17:39.362366 00:15:5d:00:c8:0a > ac:4b:c8:40:e1:cf, ethertype IPv4 (0x0800), length 2154: (tos 0xb8, ttl 63, id 17692, offset 0, flags [none], proto UDP (17), length 2140)
    98.111.XXX.XXX.54316 > 208.54.66.193.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001 cookie d9eb36016a736218->995bd98df145f5d7: child_sa  ikev2_auth[I]:
    (v2e: len=2076)
22:17:43.359028 00:15:5d:00:c8:0a > ac:4b:c8:40:e1:cf, ethertype IPv4 (0x0800), length 2154: (tos 0xb8, ttl 63, id 17693, offset 0, flags [none], proto UDP (17), length 2140)
    98.111.XXX.XXX.54316 > 208.54.66.193.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001 cookie d9eb36016a736218->995bd98df145f5d7: child_sa  ikev2_auth[I]:
    (v2e: len=2076)
22:17:50.559339 00:15:5d:00:c8:0a > ac:4b:c8:40:e1:cf, ethertype IPv4 (0x0800), length 2154: (tos 0xb8, ttl 63, id 17694, offset 0, flags [none], proto UDP (17), length 2140)
    98.111.XXX.XXX.54316 > 208.54.66.193.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001 cookie d9eb36016a736218->995bd98df145f5d7: child_sa  ikev2_auth[I]:
    (v2e: len=2076)
22:18:03.519461 00:15:5d:00:c8:0a > ac:4b:c8:40:e1:cf, ethertype IPv4 (0x0800), length 2154: (tos 0xb8, ttl 63, id 17695, offset 0, flags [none], proto UDP (17), length 2140)
    98.111.XXX.XXX.54316 > 208.54.66.193.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001 cookie d9eb36016a736218->995bd98df145f5d7: child_sa  ikev2_auth[I]:
    (v2e: len=2076)
22:18:23.950443 00:15:5d:00:c8:0a > ac:4b:c8:40:e1:cf, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 63, id 17696, offset 0, flags [none], proto UDP (17), length 29)
    98.111.XXX.XXX.54316 > 208.54.66.193.4500: [udp sum ok] isakmp-nat-keep-alive

None of the IP addresses (192.168.0.234, 98.111.XXX.XXX, or 208.54.66.193) show up in firewall logs.
Could this be a pfSense issue or possibly related to the Windows host?

PS: Not sure if it's relevant: If I ping the CellSpot from the pfServer it will only respond if the packet size is 475 or less.
ping -s 472 192.168.0.234 <-- This works
ping -s 473 192.168.0.234 <-- This doesn't

grink

Did you manage to get your femtrocell to work? I'm experiencing the same issue, but Wi-Fi calling works from my phones.

chpalmer

We got this to work with 2 of these devices on the same property.. If I remember right we made them a static port entry in "outbound NAT"..

But I know I also made inbound firewall rules from the server they connect to, to the LAN address of the devices.