01-03-2009 3:21 PM
It is a counter-intuitive configuration, so after trial and error for the past few hours, I've figured out how to do it. The directions are:
Open a web browser to your homeportal (default is 192.168.1.254)
Have the password for your 2Wire gateway handy
1. Click the Home Network icon and then click Advanced Settings
2. Enable the Public Routed Subinterface
3. Enter the public routable IP address that AT&T assigns you as the gateway into the Router Address box, and the Subnet Mask that they've assigned you in the Subnet Mask box.
4. To set up your first device, connect it to the 2Wire Home Portal, and set it up to use DHCP. The device will take a private address from the 2Wire.
5. Click the box on the right side of the Advanced Settings window named "Edit Address Allocation"
6. Find the device that you want to put the Public IP Address onto.
7. Uncheck the "Firewall Protection" box to turn off the inbound firewall to that device (if you wish, you can leave it checked and only open the ports that you need to use in the Firewall configuration)
8. In the "Address Assignment" associated with your device, click the dropdown box and find and select "Public (select WAN IP Mapping)"
9. In the WAN IP Mapping, choose the address that you want to use from the dropdown box
10. Click "Save" at the bottom of the page. When the page refreshes, you'll see that your device needs a "DHCP Renew"
11. Go back to the device that you want to connect, and refresh its DHCP address (on a Linksys or Netgear router, you can just click Save Settings or Apply on the Setup window to refresh the DHCP address). The results of the DHCP renew can be seen on the Status page of either device, or on a Windows PC, using the "ipconfig /all" command in a CMD window.
12. On the 2Wire Home Portal, click Cancel to return you to the Home Network > Advanced Settings window, and you'll see that your device has taken the new public IP address. If you click on the "Edit Address Allocation" again, you'll see that your Device Status is "Connected DHCP"
13. After doing this, I went back to my device and set the IP address in the setup to a static IP.
Adding a second device is a basic repeat of the procedure. I'm having problems right now adding a 3rd device, which may require that I restart the Home Portal - I'll do that later tonight and report back on the status of the 3rd device.
11-23-2009 3:21 AM
What do you mean, "all traffic from AT&T would be directed to the RG"? If the two entities speak Ethernet to each other, as they apparently are, at least I'd have the option of spoofing the RG's MAC address. I've already seen upstream traffic from the RG in response to blocked incoming TCP connection requests to port 445. It looks like an ordinary TCP/IP/Ethernet frame except that a VLAN is in use.
11-23-2009 11:40 AM
ICMP shouldn't be blocked. Although, there are routers in AT&T's network that treat ICMP echo packets as very low priority, so sometimes those routers don't respond.
The issue is the upstream routes. When the RG authenticates, it will get a pre-assigned outside IP address. Then, your static IP subnet is routed to the RG, because the next upstream AT&T router has a route to that static block, and the next hop will be the RG. The only way to get that traffic to your router would be to spoof the RG's MAC (don't know how you would do that with both your router and the RG on the same Ethernet segment), or to have AT&T point the next hop for your static block to your router, which would require your router to have a second, independent outside IP address, neither of which AT&T will do.
I suppose if all traffic went through your router and you passed anything that wasn't assigned to your IP static block to the RG unmodified (i.e. route the RGs traffic at layer 2 and your static block at layer 3), you might get it to work. You'd need a 3-interface custom Linux box to do it. You'd also have to program in your own QOS to make sure that video packets to the RG get priority over Internet traffic.
Seems really complicated for not much benefit, though.
11-23-2009 1:18 PM
I don't think anyone has ever tried that, but it doesn't seem like it would work. If you had your own VDSL2 modem, and it connected to a switch in which you had both the RG and your router plugged in, it's possible the RG would be able to authenticate and come up, but your router wouldn't. All traffic from AT&T would be directed to the RG, and your router, even if it authenticated, couldn't get an outside IP address, and it can't share the one assigned to the RG.
I doubt seriously that you could get AT&T to route your static IP block to your own router.
Actually there is a fun thread over on dslreports. A user 'bclbob' spent the time to confirm that it was not really going to work due to use the 2-Wire for the EAPOL. So enjoy the read.
11-23-2009 1:45 PM
That's an extraordinarily interesting thread. It basically confirms that what ka9q wants to do could theoretically be done with a correctly programmed Linux box.
1. Need a VDSL modem that will sync. Plug it's Ethernet into Linux box interface A.
2. Need to plug Linux box Ethernet interface C into the RG's red broadband port.
3. Need to plug Linux box Ethernet interface B into a switch that comprises the private network that will run with the static IPs.
Now the Linux box has to function in kind of a strange way. It needs to inspect the Ethernet frames coming into ports A & C, and if they don't involve the static IP addresses, then just bridge the packet to the other interface at layer 2. This will allow the RG to properly authenticate (using MAC address, 802.1x, and EAPOL).
If an incoming packet to port A is destined for a static IP, then the Linux box routes it to interface B at layer 3. Traffic from the static IPs into interface B gets routed out interface A, spoofing the RG's MAC address.
I don't know enough about Linux to know what networking packages would be required to make this work, or if kernel mods would be required (probably). But theoretically it could work. Then the computers on the static IPs wouldn't be subject to the limitations of the RG.
Initially, what you'd need to do is just set up straight bridging from A to C, and log some packets so that you can see what VLANs are involved, MAC addresses, etc.
11-23-2009 2:05 PM
"I suppose if all traffic went through your router and you passed anything that wasn't assigned to your IP static block to the RG unmodified (i.e. route the RGs traffic at layer 2 and your static block at layer 3), you might get it to work. "
Yes, exactly. That would be a better idea than using a conventional bridge to tie them together.
"You'd need a 3-interface custom Linux box to do it."
Two, actually. One for the modem and one for the Uverse gateway. The Linux box would copy packets between the interfaces, intercepting those intended for my static network.
"You'd also have to program in your own QOS to make sure that video packets to the RG get priority over Internet traffic."
I wouldn't have any control over downstream traffic priority; when a packet comes in from the modem, I'd have to handle it ASAP. My modem trained to 25+ Mb/s, which is quite fast by DSL standards but still well within the real-time capability of Linux on typical modern hardware.
"Seems really complicated for not much benefit, though."
It's a matter of principle; I want my network connections to be totally transparent, as they were in the "good old days".
I do have another plan, which is to set up OpenVPN on an unhosted virtual private server somewhere and buy a block of IP addresses for it on the hosting company's network. Then I could get a transparent static IP address block over any kind of Internet connection, even from behind a NAT. I run into crippled networks often enough when I travel that this would be invaluable no matter what I end up doing for my home network.
11-23-2009 2:12 PM
Yes, thanks for the link to that thread! It is indeed extraordinarily interesting. It also confirms my problem with ICMP.
11-23-2009 2:54 PM
"Two, actually. One for the modem and one for the Uverse gateway. The Linux box would copy packets between the interfaces, intercepting those intended for my static network."
D'oh. Or three, to connect my LAN directly. I've long used a Soekris net4801 running Linux as my local router. It has three Ethernet ports and draws maybe 5 watts. It's slow by modern PC standards but has been plenty fast enough to handle a cable modem at full speed.
12-08-2009 9:45 AM
> This will prevent the computers on our network from talking directly to the set top TV box, but I'm not sure that matters; are there any useful
> services running on the set top box? I see it listening on ports 8080 and 8086 but they don't seem to be webservers.
I found that any call to port 8086 will reboot a stb, even a simple port scan:
nc -v -z -n 192.168.1.69 1-10000
(UNKNOWN) [192.168.1.69] 8086 (?) open
(UNKNOWN) [192.168.1.69] 8080 (?) open
12-11-2009 6:03 PM
Ah, so THAT's why my box would behave differently when I went back after a port scan to see what it had on port 8086. It was in the process of rebooting! I hadn't even noticed.
05-03-2010 12:29 AM
I DO NOT want ANY kind of firewalling, port or protocol blocking on these static IP addresses, in either direction. None whatsoever. Again the RG supports this but by default it provides inbound protection, yet allows you to easly configure the Firewall to allow individual services or use the "Allow All Applications" setting on the Firewall configuration page to allow all unsolicited inbound traffic through to each client.
I am running OpenVPN on port 1194 on one of the servers behind the RG firewall. Yes I have a static IP block and the same server's other ports (e.g. port 80 and 443 ) are accessible from outside using it's (public ) static IP. However the RG firewall seems to be blocking traffic on port 1194. I am using the latest version of RG software i.e. 6.1.9.x and set the firewall settings for the server running OPENVPN to "DMZplus" as well as the "node" i.e. the RG's static IP's firewall settings to "DMZplus" also. No luck. Any ideas ?