We just had to switch a customer from NAT to bridged because their Verizon femtocell would not work in NAT mode. I thought this was some packet fragmentation issue that was corrected in 13.4?
Unless perhaps Verizon is doing something new now.
--
bp
We have seen more problems with the AT&T units than Sprint/Verizon but if a customer calls in, we immediatley move NAT and PPPoE to the cusomters router and it works fine. We havent tried 13.4 though.
@rosborne wrote:We have seen more problems with the AT&T units than Sprint/Verizon but if a customer calls in, we immediatley move NAT and PPPoE to the cusomters router and it works fine. We havent tried 13.4 though.
What release were you on that you saw issues with the AT&T Microcells? That issue should have been resolved with 13.2.
@jamus wrote:
@rosborne wrote:We have seen more problems with the AT&T units than Sprint/Verizon but if a customer calls in, we immediatley move NAT and PPPoE to the cusomters router and it works fine. We havent tried 13.4 though.
What release were you on that you saw issues with the AT&T Microcells? That issue should have been resolved with 13.2.
As stated in the subject line, this is 13.4 on FSK.
We also have had more issues with AT&T and their "upside-down Y" POS from Cisco. Very few issues with Sprint or Verizon, but every installation seems to be a little "different".
Whatever the issue(s) is/are, we apparently do not have a solution for NATted SMs.
We would not have to NAT if there was a way to retrict the number of MAC addresses that are allowed to bridge.
--
bp
Hello GlueGuy,
My version question was aimed at rosborne, who said "We havent tried 13.4 though".
Just to clarify, you generally don't have problems with Verizon femtocells, but you recently ran into an issue? Do you know if there's a difference in Verizon hardware or software? Do you know if the customer has their microcell either directly attached, attached to a switch, or attached to a router also doing nat?
And to clarify your request, do you want to limit to a number (10), or actually be able to specify the mac addresses that you want to bridge?
@jamus wrote:
Just to clarify, you generally don't have problems with Verizon femtocells, but you recently ran into an issue? Do you know if there's a difference in Verizon hardware or software? Do you know if the customer has their microcell either directly attached, attached to a switch, or attached to a router also doing nat?
And to clarify your request, do you want to limit to a number (10), or actually be able to specify the mac addresses that you want to bridge?
We have not run into issues with Verizon femtocells before, but that is not to say that we haven't had issues. We often don't hear about issues if customers don't call us.
In this particular instance, I believe the femtocell was attached to their router. As is the case with 95% (+) of our subscribers, we generally NAT to them. We have often had issues with Apple routers, as they will by default go into bridge mode if they detect a NATed network connection (the dreaded double NAT). This has the effect of overwhelming the limited NAT capability of the SM.
We use NAT to help suppress very common issues among non-technical customers. However, it seems to be increasingly common that NAT can cause as many/more issues than just having decent filtering for the customer's equipment. As most of our subscribers are home owners, and they typically have a WiFi router attached to our equipment, we would want to ensure that the customer's router is the one and only device attached to the SM.
I suppose the simplest method would be to lock the MAC address of the "approved device", but if there was a simple way to allow one, and only one, device/MAC through the bridge interface, that would be the way to go. If there were some more complicated connection required, we would handle those rare instances on a case-by-case basis.
Hope this clarifies,
--
bp
We just got another report from a subscriber attempting to use "WiFi calling" with an iphone 6.
It appears that this feature will not work with double-NAT. This particular customer solved his problem by switching his home router into bridge mode.
As the SM is not a great router, it seems that continueing to use the NAT on the SM is having diminishing returns. We are now having more and more issues related to NAT in the SM.
It would be much simpler to have a bridge mode that solves the problems we currently are using NAT for; and that is limiting the number of public IPs issued per subscriber. If the SM bridge mode could be limited to passing data for a single MAC address, that would solve the problem, and we could move on.
--
bp
I remember the problem before was NAT fragmentation which was fixed in 13.2 I believe.
Not working through double NAT sounds like the carrier is doing some kind of VPN which is very common. I see the AT&T boxes sending and receiving on UDP port 4500. This is IPSEC. I'd figure that DMZ on the SM shouldn't have any problem with this. Since you said it works after they put their router in bridge mode, maybe it's the NAT on their router that's not lettting the IPSEC through.
That's all I got. We're not running NAT on any SMs yet, but plan to once 13.4.1 is done.
Oh. This reply?
We've had so many (and increasing) issues with Canopy NAT that I honestly feel it's time to go another direction.
We've never had an issue with Canopy bridging mode except for the fact that it's possible for a subscriber to pull multiple public IPs. The best way that I can think of to manage this is if the Canopy bridge could somehow restrict bridge mode to a single device, then we could kiss all these issues goodby and move on.
--
bp