[SGVLUG] ATT's 2wire products are braindead
Matthew Campbell
dvdmatt at gmail.com
Fri Aug 2 09:33:09 PDT 2013
Thanks again Scott, I read those posts also. Nothing pertained to the
problems I am having.
Your thought about other settings is interesting. I was thinking of
relaxing the DOS filters to see if they were triggering on the second
packet. That was the only thing I could think of that would allow one
packet, then block the whole subdomain on the second packet.
The problem is that you can't turn off the firewall on this box. When you
choose DMZ plus to allow all traffic the router automatically directs all
incoming traffic to the first device it discovered after original power-up
witch is the tablet the AT&T technician used to configure the box. There
is no way to change this direction target. If I select another target the
DMZ option disappears out of the menus. and I am only allowed to configure
individual port direction. This firmware is badly flawed.
Ok, figured it out. The router will only allow DMZplus to an IP address on
the same /24 that the LAN ports are configured to. Because I am asking it
to direct traffic to a VM on the same /16 it blocks the target address
automatically because nobody would ever run anything but 192.168 in their
home or office...
This is the same mentality that led them to disable the ability to
configure a static IP address on the LAN ports. I had to turn on the 2wire
DHCP server and give it an address range of 1 to allow configuration of
those ports. Who programs this? Can it be more stupidly broken even if
they tried?
Too bad AT&T violently disallows DD-WRT on the router. :(
Well, back on the phone with AT&T for another 2 hours of bliss...
Matt
On Thu, Aug 1, 2013 at 9:22 PM, Scott Packard <spackard at gmail.com> wrote:
>
> On Thu, Aug 1, 2013 at 7:53 PM, Matthew Campbell <dvdmatt at gmail.com>wrote:
>
>> > Any chance AT&T blocks incoming port 22
>> Scott, good ideas there. I can confirm that AT&T is not blocking the SSH
>> port as my router's firewall log is showing the incoming packets and
>> admitting to dropping them. See the log excerpt at the bottom of the
>> initial email in this chain:
>> INF 2013-07-26T20:15:42-07:00 fw src=162.200.153.165 dst=172.28.1.2
>> ipprot=6 sport=40058 dport=22 Session Matches User Pinhole, Packet Passed
>> INF 2013-07-26T20:15:42-07:00 fw src=162.200.153.165 dst=172.28.1.2
>> ipprot=6 sport=40058 dport=22 Drop traffic to 172.16.0.0/12
>> This shows that the packets are getting through to the 3801, that it is
>> recognizing that I have defined a pinhole rule to pass port 22 traffic on
>> to 172.28.1.2 and that it is dropping all traffic to the entire 172.16/12
>> subnet from the second packet on.
>>
>
>
> I don't own one of these, so take what I say with a grain of salt.
> Maybe there's another setting that needs to be relaxed to allow the
> traffic through.
> I had a DSL modem that wouldn't allow traffic through until I went to
> another configuration page and relaxed the "security" via a bulk setting.
> (The application being blocked was outbound IMAP, I think; Outlook
> connecting to a popular public mail server. Was helping out a Windows
> consultant.)
> Your trace gives me the feeling it passes one rule and is blocked by
> another.
>
> I assume you've Googled for the answer already (can see you did). Someone
> posts that even configuring it to be very close to a bridge it still will
> likely block incoming port 22.
>
> http://forums.att.com/t5/forums/forumtopicprintpage/board-id/gateway/message-id/182/print-single-message/true/page/1
>
> Another person says his was working, then stopped, and his fix was his
> internal IP was statically assigned on the server but within the modem's
> DHCP range. He fixed it by going static IPs only.
> http://www.dslreports.com/forum/r25531146-2WIRE-Port-Forward-Problem
> In the thread someone says you can use either DMZPlus or open ports, but
> not both.
>
> Regards, Scott
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sgvlug.net/pipermail/sgvlug/attachments/20130802/3a792518/attachment.html>
More information about the SGVLUG
mailing list