Jamie Bowden <ja...@photon.com> writes:
> I don't care for the Actiontec boxes either, but the STB program
> guides and other features don't work without it, so I have mine
> forward all IP traffic unmolested to my own as the DMZ host
Actually this can be worked around. My config has SA, er, Cisco STBs
and a Netgear MCAB1001 MOCA to Ethernet bridge. This configuration is
very unsupported, which is why I keep a completely unmolested
Actiontec around to plug in if I have to have the guys at Verizon take
a look at it.
A little magic in dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1 ;
option domain-name-servers 71.252.0.12 ;
default-lease-time 86400 ;
max-lease-time 172800 ;
host stb100 { hardware ethernet 0:23:be:xx:xx:xx ; fixed-address
192.168.1.100 ; }
host stb101 { hardware ethernet 0:21:be:xx:xx:xx ; fixed-address
192.168.1.101 ; }
host stb102 { hardware ethernet 0:25:2e:xx:xx:xx ; fixed-address
192.168.1.102 ; }
host stb103 { hardware ethernet 0:21:be:xx:xx:xx ; fixed-address
192.168.1.103 ; }
}
and then some appropriate holes in the firewall (/etc/pf.conf):
# for STBs
pass in quick on $extif inet proto tcp from any to ($extif) port 35000 rdr-to
192.168.1.100 port 7547
pass in quick on $extif inet proto tcp from any to ($extif) port 35001 rdr-to
192.168.1.101 port 7547
pass in quick on $extif inet proto udp from any to ($extif) port 63145 rdr-to
192.168.1.100 port 63145
(I only have one DVR and one STB - the definitions for extra STBs came
out of the Actiontek. Not sure what I'll end up needing to do if I
get another DVR or STB in order to get them properly provisioned...)
Guide and VOD work fine. I don't feel like playing stuff from a PC on
the STBs badly enough to be willing to cram my whole life into a flat
192.168.1/24, so I give those up.
I've often wondered whether the boxes care about double-hopped NAT.
Perhaps one of these days I'll try putting the Actiontek and some new
pf.conf rules in place of the Netgear and give that a try.
> (thus
> the dual layer of [P|N]AT you see). It's just UDP/TCP 53 traffic
> that's not flowing for whatever reason; it's every device in the
> house phones, tablets, computers, you name it, so I'm not inclined
> to attribute it to malware. My neighbor was also seeing it (and
> like last time, it seems to have magically resolved itself after
> ~1.5h). I'm just wondering what Verizon is DOING that they are
> screwing up their own DNS traffic. If they were capturing my
> queries and sending them to their own servers (I actually have
> Google's public facing servers at the top of the list handed out by
> DHCP) that would be one thing (irritating to be sure, but they
> aren't, so it's not), but when I'm explicitly hitting a name server
> down the street in Reston that VZ run and it's failing the same way?
> It makes me wonder.
No idea, just a datapoint that we're Not Seeing That Here... but if
it is failing on google's public dns servers that's troubling to say
the least.
-r
