Comcast Business Service - What am I looking at?

HCHTech

Well-Known Member
Reaction score
3,835
Location
Pittsburgh, PA - USA
I'm reviewing a 'friendly takeover' client from another company in my area. I've run into something I've not seen before so at the risk of exposing my ignorance, thought I would post here.

Customer has a single static IP service with Comcast business. They have a standard business gateway device - 8 LAN ports & built-in dual-band wifi. They also have a Sonicwall connected to the gateway, and it is pulling the public IP directly - as if the gateway is in bridge mode (or comcast's pseudo-bridge mode). All of the computers and other company devices are inside the firewall None of this is unusual, except they also have a handful of wireless phone base stations, which are connected directly to the Comcast gateway and not running through the Sonicwall. This surprises me since anytime I've seen a firewall pull the public IP directly for a customer with Comcast business, the rest of the LAN ports on the comcast gateway are inactive.

In this customer's case, it appears one of the LAN ports is serving the public IP to the Sonicwall, while the rest of the LAN ports are giving DHCP addresses on the 10.1.10.0/24 network.

If I look at the Connected Devices pages of the Comcast gateway, I see this:
1706215113969.png

I don't understand how the Sonicwall can be on the DHCP list showing the public IP, while other devices on that same list are on the native 10.1.10.0/24 network.

In the Comcast Network section, I see this (The public IP being pulled by the Sonicwall is the one starting with 50.248 ):

1706214280583.png

DHCP on the gateway is clearly active:
1706214748080.png

Does this imply there is some back-end routing going on somehow? There are no NAT rules or Static Routes in the Comcast gateway.

Everything is working, but I have no idea if this is an efficient setup or not. Usually the fewer things happening between the firewall and the internet the better, as far as I'm concerned. I'd rather bring the phone stuff inside of the firewall and manage them on their own VLAN, but this apparently unusual configuration is giving me pause.
 

Attachments

  • 1706213922453.png
    1706213922453.png
    144.7 KB · Views: 0
  • 1706214927538.png
    1706214927538.png
    21.9 KB · Views: 0
I only skimmed it but...all the Comcast gateways I've set up our networks on (quite a few )...yes you can leave the native DHCP running on the gateway and it will still serve up its own little NAT network..the 10.1.10.0/24 and you can still have your own firewall with the static public IP. I do always disable the built in wifi. The older models of Comcast gateway, had a different way to setup the static public IP, if you flipped that switch..."disable firewall for true public IP subnet passthrough" or whatever it was called, yeah that killed the NAT on certain models (I think the Netgear or SMC based ones). But the new-er ones happily co-exist.

Which is fine if you have some IoT-ish things that you don't want on your managed LAN. Just plop them there.
 
Ok, thanks - I just hadn't run into this setup before. What's happening with this client is that the phones (from Verizon, why make it simple) are all connected straight to the gateway, and the computers are all behind the firewall. They are having problems with the phones dropping calls. Verizon says the gateway is doing DPI and that's the problem, but of course all of those setting are disabled on the gateway. Comcast says "No we're not, and everything looks fine from our end!", but the problems continue. I suggested they either try it with the phones inside the firewall on their own VLAN or maybe pick a vendor and have both phones and internet with the same company - that way, they would take responsibility for their own equipment (well, maybe they would).

We'll see how it goes.
 
is that the phones (from Verizon, why make it simple) ... Verizon says the gateway is doing DPI and that's the problem, but of course all of those setting are disabled on the gateway. Comcast says "No we're not, and everything looks fine from our end!", but the problems continue. or maybe pick a vendor and have both phones and internet with the same company - that way, they would take responsibility for their own equipment (well, maybe they would).

Yikes...I have not run across a...half 'n half setup like this. Surely a recipe for "finger pointing game" such as you are seeing here!

One of the advantages of "ISP provided VoIP phones"...is the ISP can control the bandwidth from their data center...VoIP systems...to the end points. It's all "last mile" stuff. The QoS is able to be managed from their data center to the end points.

Instead of ...having VoIP systems traverse various public internet routes, with "who knows how many hops" and latency, etc.

Yeah, I'd pick one!
 
I've seen this setup several times before. Not my preferred way but for someone, the EU, who likes to kludge things together is a option. Not preferred mind you.
 
Back
Top