configuring devices behind the Public Routed Subinterface

[ka9q]

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.

[SomeJoe7777 ACE - Geek]

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.

[dave006]

---

SomeJoe7777 wrote:

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.

http://www.dslreports.com/forum/r22423850-Using-a-3rd-party-VDSL-modem

Dave

[SomeJoe7777 ACE - Geek]

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.

[ka9q]

"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.

[ka9q]

Yes, thanks for the link to that thread! It is indeed extraordinarily interesting. It also confirms my problem with ICMP.

[ka9q]

"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.

[kyle470]

> 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

[ka9q]

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.

[francisplace]

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 ?