Just ran a couple of quick checks, and we do have quite a few of those
too (port 4500 UDP). I checked a half dozen or so, and they are all
going to either Verizon or AT&T.
We have large portions of our network with poor or no cell coverage, so
it may be a bigger issue with us.
I think we get "some" number of these that people try, and it doesn't
work, so they return the femtocell to either Verizon or AT&T, and we
never hear about it.
I would just like th/is/ese problem(s) to go away.
bp
<part15sbs{at}gmail{dot}com>
On 10/15/2015 4:38 PM, George Skorup wrote:
I meant my reply to your post on the Cambium community.
I honestly don't know how many customers we might have using these
things (we have decent cell coverage). I looked through some netflow
data and found quite a few customers with UDP 4500 traffic. The
destinations are Verizon and AT&T IP addresses. These are obvious
because they're also hitting NTP servers on the carrier's networks. A
quick google search tells me this UDP 4500 stuff is IPSEC IKE NAT
traversal and keepalive. That's why I asked if you've torched their
traffic. Maybe the carriers do these things differently in your
region. Those aren't going through the Canopy NAT, but they are behind
double NAT. So I have no idea. Maybe it is still something with the
Canopy NAT implementation.
On 10/15/2015 3:58 PM, Bill Prince wrote:
Not sure if I saw your post George. I did a couple of searches, but
did not find anything matching.
Since 13.4, we've tracked the NAT table, and the subscriber that
called this in had zero entries in their NAT table until they
switched their router into bridge mode. So I'm fairly certain they
were on the DMZ. That said, the sub is a programmer/tech, so he's not
your average rube. He called in to report switching their router to
bridge mode fixed his AT&T WiFi calling problem. We did not torch the
link.
I call it NAT without PAT, or NAT minus PAT, or NAT no PAT.
bp
<part15sbs{at}gmail{dot}com>
On 10/15/2015 1:29 PM, George Skorup wrote:
I assume you read my post? Have you ran torch on these customers to
see what the actual traffic is? I believe they all use an IPSEC VPN.
Should work through one layer of NAT (obviously does as you've
seen), but I don't know why not also through the SM DMZ which is
really NAT, not PAT. What's the term now, NAP-T or something like
that is what we all call "NAT" generally.
On 10/15/2015 3:14 PM, Bill Prince wrote:
BTW - this is with the SM on the 13.4 release (FSK in this
particular case).
bp
<part15sbs{at}gmail{dot}com>
On 10/15/2015 1:12 PM, Bill Prince wrote:
I think we have determined that the new AT&T "WiFi calling"
feature will not work with double NAT (even when the customer's
router is on the DMZ). This is the same behavior we've seen on
T-mobile. It seems to work if the customer router is in bridge
mode, or the SM is in bridge mode.
