Ask a question
Search in U-verse Forums

U-verse Forums

Reply
Highlighted
Posted Dec 28, 2009
6:11:50 AM
View profile
Configuring DMZPlus or port-forwarding for LAN access

Happy Holidays to all! I'm hoping someone can help me out here...

 

About 2 weeks ago, I switched from a local DSL provider to AT&T U-Verse at my new home, and am trying to get the AT&T 3800HGV-B Gateway to allow access to my LAN machines from the public internet (web, cvs/svn, mail, imap, nfs, etc.) and am not having the best of luck with many different configuration attempts.

 

In my previous DSL configuration, I had a DSL modem directly attached to the phone line, and a Buffalo Wireless WHR-HP-G54 attached to that, handling the firewalling and routing. The WHR's WAN side had the public IP of the DSL connection, and routed all traffic hitting that public interface into the local LAN clients that were on the 10.0.1.x segment. All machines were connected to ports on a switch that was plugged into one of the switched ports on the back of the WHR. This all worked flawlessly for about 3 years.

 

Now I'm on U-Verse with the 3800HGV-B, and I can't seem to replicate the same sort of function. Here's what I have tried and my current configuration: 

 

The 3800HGV-B has a public IP of 99.16.211.3 on the WAN side and a local IP of 10.0.1.1 on the LAN side. I've connected the WHR to the 3800 via the WAN port on the WHR, and configured it with "DMZPlus", in the hopes that the WHR's WAN side would be given the 99.16.211.3 address. 

 

When that happens, the WHR has 99.16.211.3 on the WAN side, and 10.0.1.2 on the local LAN side. 

 

At this point, I have the 3800 assigned with 10.0.1.1, acting as a bridge, using DMZPlus to pass all traffic to the WHR sitting at 10.0.1.2, with a WAN IP of 99.16.211.3. 

 

On the WHR, I configure some port-forward rules so that all incoming requests on 99.16.211.3 for port 80, go through the WHR, and get forwarded to the internal webserver sitting on 10.0.1.4. 

 

This fails. Traffic never gets through to the webserver machine. Likewise for any other services on any other port of any other internal LAN machine. 

 

So then I unset the DMZPlus and tried to just use the 3800's onboard Firewall Settings option to point "SSH Server" and "Web Server" to two different internal machines. This also fails. No traffic seems to get past the 3800 into the WHR, and into the local LAN segment. 

 

What I found interesting, is that the 99.16.211.3 IP is publicly accessible, but I have a block of 8 static IPs (5 usable) on a completely different subnet. In the "Local Network" -> "Advanced Settings" dialog of the 3800's config, I see: 


Public Routed Subinterface    
Router Address: 75.54.193.190 
Subnet Mask:    255.255.255.248


The IP block I have begins with the 5 IPs prior to .190 there. Shouldn't the WAN IP that the 3800 uses and the WHR receives be one of those IPs, and not the 99.16.211.3 IP?

What is the "right" way to configure this, so public access from the live Internet, can interact with services running on my local LAN machines on the 10.0.1.x segment? 

 

Thanks in advance!

Happy Holidays to all! I'm hoping someone can help me out here...

 

About 2 weeks ago, I switched from a local DSL provider to AT&T U-Verse at my new home, and am trying to get the AT&T 3800HGV-B Gateway to allow access to my LAN machines from the public internet (web, cvs/svn, mail, imap, nfs, etc.) and am not having the best of luck with many different configuration attempts.

 

In my previous DSL configuration, I had a DSL modem directly attached to the phone line, and a Buffalo Wireless WHR-HP-G54 attached to that, handling the firewalling and routing. The WHR's WAN side had the public IP of the DSL connection, and routed all traffic hitting that public interface into the local LAN clients that were on the 10.0.1.x segment. All machines were connected to ports on a switch that was plugged into one of the switched ports on the back of the WHR. This all worked flawlessly for about 3 years.

 

Now I'm on U-Verse with the 3800HGV-B, and I can't seem to replicate the same sort of function. Here's what I have tried and my current configuration: 

 

The 3800HGV-B has a public IP of 99.16.211.3 on the WAN side and a local IP of 10.0.1.1 on the LAN side. I've connected the WHR to the 3800 via the WAN port on the WHR, and configured it with "DMZPlus", in the hopes that the WHR's WAN side would be given the 99.16.211.3 address. 

 

When that happens, the WHR has 99.16.211.3 on the WAN side, and 10.0.1.2 on the local LAN side. 

 

At this point, I have the 3800 assigned with 10.0.1.1, acting as a bridge, using DMZPlus to pass all traffic to the WHR sitting at 10.0.1.2, with a WAN IP of 99.16.211.3. 

 

On the WHR, I configure some port-forward rules so that all incoming requests on 99.16.211.3 for port 80, go through the WHR, and get forwarded to the internal webserver sitting on 10.0.1.4. 

 

This fails. Traffic never gets through to the webserver machine. Likewise for any other services on any other port of any other internal LAN machine. 

 

So then I unset the DMZPlus and tried to just use the 3800's onboard Firewall Settings option to point "SSH Server" and "Web Server" to two different internal machines. This also fails. No traffic seems to get past the 3800 into the WHR, and into the local LAN segment. 

 

What I found interesting, is that the 99.16.211.3 IP is publicly accessible, but I have a block of 8 static IPs (5 usable) on a completely different subnet. In the "Local Network" -> "Advanced Settings" dialog of the 3800's config, I see: 


Public Routed Subinterface    
Router Address: 75.54.193.190 
Subnet Mask:    255.255.255.248


The IP block I have begins with the 5 IPs prior to .190 there. Shouldn't the WAN IP that the 3800 uses and the WHR receives be one of those IPs, and not the 99.16.211.3 IP?

What is the "right" way to configure this, so public access from the live Internet, can interact with services running on my local LAN machines on the 10.0.1.x segment? 

 

Thanks in advance!

Configuring DMZPlus or port-forwarding for LAN access

1,898 views
36 replies
(0) Me too
(0) Me too
Reply
View all replies
(36)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 6:49:44 AM
0
(0)
Scholar

You have the WHR using 10.0.1.0 on its LAN.

You have the RG using 10.0.1.x on its LAN, which is also the WAN interface for the WHR.

 

This is a conflict, and the result is that your WHR won't be able to communicate with devices on the RG LAN.  I'm not sure whether that is the cause of your problems, but it could well be.  I suggest you set the RG back to its default of 192.168.1.254 with 192.168.1.* as is LAN.

 

I'm not sure about that static block, as I have no experience with that.  My understanding is that you could manually configure your WHR to use one of those static IPs  on its WAN, and the RG would then recognize that.  I'm not sure whether there is a way to have the RG assign that with DHCP.  Even with that static assignment, you would still have a potential conflict between the RG LAN ips and the WHR LAN ips.

 

 

You have the WHR using 10.0.1.0 on its LAN.

You have the RG using 10.0.1.x on its LAN, which is also the WAN interface for the WHR.

 

This is a conflict, and the result is that your WHR won't be able to communicate with devices on the RG LAN.  I'm not sure whether that is the cause of your problems, but it could well be.  I suggest you set the RG back to its default of 192.168.1.254 with 192.168.1.* as is LAN.

 

I'm not sure about that static block, as I have no experience with that.  My understanding is that you could manually configure your WHR to use one of those static IPs  on its WAN, and the RG would then recognize that.  I'm not sure whether there is a way to have the RG assign that with DHCP.  Even with that static assignment, you would still have a potential conflict between the RG LAN ips and the WHR LAN ips.

 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

2 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 7:03:22 AM
0
(0)
Teacher

No no... RG is 10.0.1.1, WHR is 10.0.1.2.. on the same segment.

 

The WAN port of the WHR is getting the public IP (99.16.211.3) from the RG via DHCP. This is all exactly how it is supposed to work. 

 

I want all of my LAN machines on the same network (i.e. 10.0.1.x). Right now, they're all configured to be on that segment: 

 

10.0.1.1 = RG

10.0.1.2 = WHR

10.0.1.3 = mail server

10.0.1.4 = webserver

10.0.1.5 = NFS server

 

...and so on.

 

 I just want the traffic hitting 99.16.211.3 (or is it 75.54.193.186-189?) to reach the machines sitting on 10.0.1.3-5.

 

No no... RG is 10.0.1.1, WHR is 10.0.1.2.. on the same segment.

 

The WAN port of the WHR is getting the public IP (99.16.211.3) from the RG via DHCP. This is all exactly how it is supposed to work. 

 

I want all of my LAN machines on the same network (i.e. 10.0.1.x). Right now, they're all configured to be on that segment: 

 

10.0.1.1 = RG

10.0.1.2 = WHR

10.0.1.3 = mail server

10.0.1.4 = webserver

10.0.1.5 = NFS server

 

...and so on.

 

 I just want the traffic hitting 99.16.211.3 (or is it 75.54.193.186-189?) to reach the machines sitting on 10.0.1.3-5.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

3 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 7:23:26 AM
0
(0)
Expert

setuid wrote:

No no... RG is 10.0.1.1, WHR is 10.0.1.2.. on the same segment.


 

They're not on the same segment.  The network between the RG LAN and the WHR WAN port is a separate network from the network on the LAN side of the WHR.

 

Those two networks MUST be on different subnets.  To have addresses from the same subnet on both sides of a router is a configuration error.

 

Reconfigure the RG to use a different subnet on the LAN.  If you don't want to use 192.168.x.x for security concerns, then use another subnet in the 10.0.x.x range.

 

Example:

 

WHR LAN: 10.0.1.1/24

RG LAN: 10.0.2.1/24

 


setuid wrote:

No no... RG is 10.0.1.1, WHR is 10.0.1.2.. on the same segment.


 

They're not on the same segment.  The network between the RG LAN and the WHR WAN port is a separate network from the network on the LAN side of the WHR.

 

Those two networks MUST be on different subnets.  To have addresses from the same subnet on both sides of a router is a configuration error.

 

Reconfigure the RG to use a different subnet on the LAN.  If you don't want to use 192.168.x.x for security concerns, then use another subnet in the 10.0.x.x range.

 

Example:

 

WHR LAN: 10.0.1.1/24

RG LAN: 10.0.2.1/24

 

Re: Configuring DMZPlus or port-forwarding for LAN access

4 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 7:39:40 AM
0
(0)
Teacher

 

That's not right at all. Nothing gets plugged into the WHR at all, other than the WAN port itself. It just happens to be a router on the same network as the machines physically plugged into the switch physically attached to the RG. It looks like this:

 

[internet] 

     |

[RG] = 10.0.1.1

   (x) = [switch] -> (x) = WHR  @10.0.1.2

   (x) = PlugLink    (x) = Mail @10.0.1.3

   (o) = unused      (x) = Web  @10.0.1.4

   (o) = unused      (x) = NFS  @10.0.1.5

                     (x) = port 5-10, other servers

 

All equipment is on the same LAN segment. The WHR just happens to be the next local IP on the same segment as the local IP of the RG. 

 

Again, this is EXACTLY how this worked behind DSL, and it worked fine.

 

Are you saying that the RG can't function properly, if it is on the same segment as another router? In other words, I can't have: 

 

RG  @10.0.1.1

WHR @10.0.1.2 

 

If that is indeed true, that's assinine! 

 

 

Given what you're suggesting, if I put the RG on 10.0.2.1, and the WHR on 10.0.1.1, and leave all LAN machines configured with 10.0.1.x addresses, they'll be able to route correctly from: 

 

99.16.211.3 -> 10.0.2.1 -> 10.0.1.1 -> 10.0.1.4 

 

Are you sure?

 

That's not right at all. Nothing gets plugged into the WHR at all, other than the WAN port itself. It just happens to be a router on the same network as the machines physically plugged into the switch physically attached to the RG. It looks like this:

 

[internet] 

     |

[RG] = 10.0.1.1

   (x) = [switch] -> (x) = WHR  @10.0.1.2

   (x) = PlugLink    (x) = Mail @10.0.1.3

   (o) = unused      (x) = Web  @10.0.1.4

   (o) = unused      (x) = NFS  @10.0.1.5

                     (x) = port 5-10, other servers

 

All equipment is on the same LAN segment. The WHR just happens to be the next local IP on the same segment as the local IP of the RG. 

 

Again, this is EXACTLY how this worked behind DSL, and it worked fine.

 

Are you saying that the RG can't function properly, if it is on the same segment as another router? In other words, I can't have: 

 

RG  @10.0.1.1

WHR @10.0.1.2 

 

If that is indeed true, that's assinine! 

 

 

Given what you're suggesting, if I put the RG on 10.0.2.1, and the WHR on 10.0.1.1, and leave all LAN machines configured with 10.0.1.x addresses, they'll be able to route correctly from: 

 

99.16.211.3 -> 10.0.2.1 -> 10.0.1.1 -> 10.0.1.4 

 

Are you sure?

Re: Configuring DMZPlus or port-forwarding for LAN access

5 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 8:26:53 AM
0
(0)
Expert

Oh my.

 


setuid wrote:

 

Nothing gets plugged into the WHR at all, other than the WAN port itself.


 

You're saying that the only thing connected to the WHR is one Ethernet cable going to it's WAN port?  And nothing plugged into it's LAN ports?

 

This is a completely incorrect setup for using your own router.  The router can't "route" anything like this.

 

 

Let's start from the beginning.  First, let's answer some questions so that we can figure out the best way to do this:

 

1. Do you have a 5 static IP block that you purchased?

2. Please list the servers and services on each that you need to have accessible from the internet.

3. Are you only doing firewalling and port forwarding from the WHR?  i.e. you're not doing anything out of the ordinary like VPN, VOIP, etc.?

 

 

Oh my.

 


setuid wrote:

 

Nothing gets plugged into the WHR at all, other than the WAN port itself.


 

You're saying that the only thing connected to the WHR is one Ethernet cable going to it's WAN port?  And nothing plugged into it's LAN ports?

 

This is a completely incorrect setup for using your own router.  The router can't "route" anything like this.

 

 

Let's start from the beginning.  First, let's answer some questions so that we can figure out the best way to do this:

 

1. Do you have a 5 static IP block that you purchased?

2. Please list the servers and services on each that you need to have accessible from the internet.

3. Are you only doing firewalling and port forwarding from the WHR?  i.e. you're not doing anything out of the ordinary like VPN, VOIP, etc.?

 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

6 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 8:31:41 AM
0
(0)
Scholar

It seems like you've gone from plugging your switch into the back (LAN side) of your WHR router in your DSL setup, to plugging your switch into the RG's LAN ports in your U-verse setup.

 

This seems completely wrong.  Why wouldn't you keep your switch plugged into the WHR router? 

It seems like you've gone from plugging your switch into the back (LAN side) of your WHR router in your DSL setup, to plugging your switch into the RG's LAN ports in your U-verse setup.

 

This seems completely wrong.  Why wouldn't you keep your switch plugged into the WHR router? 

Re: Configuring DMZPlus or port-forwarding for LAN access

7 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 8:32:31 AM
0
(0)
Teacher

1. Do you have a 5 static IP block that you purchased?

 

Yes, 75.54.193.185-75.54.193.190, where 75.54.193.190 is the one identified by the RG as the router address on the "Public Routed Subinterface" (whatever they define that to be)

 

2. Please list the servers and services on each that you need to have accessible from the internet.

 

smtp (sendmail on 25), dns (using bind9 on 53), web (apache on 80/443), ssh (port-knocked on high ports), imap/imaps (dovecot on 143/993), ldap/ldaps (OpenLDAP on 389/636) cvs (2401), and a handful of others.

 

3. Are you only doing firewalling and port forwarding from the WHR?  i.e. you're not doing anything out of the ordinary like VPN, VOIP, etc.?

 

Correct, I am only port-forwarding from WHR to local servers inside my LAN segment. No VPN, no VoIP, nothing else. This connection ONLY has Internet on it, no television, no voice, no land-lines at all.

1. Do you have a 5 static IP block that you purchased?

 

Yes, 75.54.193.185-75.54.193.190, where 75.54.193.190 is the one identified by the RG as the router address on the "Public Routed Subinterface" (whatever they define that to be)

 

2. Please list the servers and services on each that you need to have accessible from the internet.

 

smtp (sendmail on 25), dns (using bind9 on 53), web (apache on 80/443), ssh (port-knocked on high ports), imap/imaps (dovecot on 143/993), ldap/ldaps (OpenLDAP on 389/636) cvs (2401), and a handful of others.

 

3. Are you only doing firewalling and port forwarding from the WHR?  i.e. you're not doing anything out of the ordinary like VPN, VOIP, etc.?

 

Correct, I am only port-forwarding from WHR to local servers inside my LAN segment. No VPN, no VoIP, nothing else. This connection ONLY has Internet on it, no television, no voice, no land-lines at all.

Re: Configuring DMZPlus or port-forwarding for LAN access

8 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 8:41:37 AM
0
(0)
Expert

OK.  Next decision:

 

You cannot use both the static IP block AND your WHR router together, the RG cannot be configured that way.  You will need to choose one or the other.

 

From the servers and services you list, you might be better off with using the static IPs and removing the WHR from your setup.  This will also simplify the configuration.

 

OK.  Next decision:

 

You cannot use both the static IP block AND your WHR router together, the RG cannot be configured that way.  You will need to choose one or the other.

 

From the servers and services you list, you might be better off with using the static IPs and removing the WHR from your setup.  This will also simplify the configuration.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

9 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 8:44:50 AM
0
(0)
Teacher

No can do. The static IPs will all point to the same physical connection, where the WHR will then port-forward services to the appropriate servers behind it, sitting on the 10.0.1.x LAN segment.

 

The servers on the 10.0.1.x LAN can't be reconfigured for the 5 statc IPs on the outside, and that won't work anyway... because some services come from different physical machines, where 5 static IPs is not enough to cover that spread. 

 

So how do I get the RG to allow the WHR to port-forward the incoming requests on those 5 static IPs to the servers behind the WHR, on my LAN? That's the real question here... 

 

No can do. The static IPs will all point to the same physical connection, where the WHR will then port-forward services to the appropriate servers behind it, sitting on the 10.0.1.x LAN segment.

 

The servers on the 10.0.1.x LAN can't be reconfigured for the 5 statc IPs on the outside, and that won't work anyway... because some services come from different physical machines, where 5 static IPs is not enough to cover that spread. 

 

So how do I get the RG to allow the WHR to port-forward the incoming requests on those 5 static IPs to the servers behind the WHR, on my LAN? That's the real question here... 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

10 of 37 (1,897 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 8:49:03 AM
0
(0)
Teacher

So you're suggesting that I go RG -> WHR -> switch, and plug all LAN equipment directly into the switch?

 

My LAN machines are all statically-defined with their 10.0.1.x addresses, so I should be able to disable DHCP on the switched ports of the RG, and leave DHCP on for the Wireless side of the RG, right?

 

Is that even possible? (My WHR allows this, but my WHR running dd-wrt has a LOT more function than the AT&T RG anyway). 

 

If I do that, and set the RG's internal IP to 10.0.2.1, and the WHR to 10.0.1.1, can the traffic hitting the external 99.x IP get routed correctly to those LAN machines plugged into the switch attached to one of the switch ports of the WHR?

So you're suggesting that I go RG -> WHR -> switch, and plug all LAN equipment directly into the switch?

 

My LAN machines are all statically-defined with their 10.0.1.x addresses, so I should be able to disable DHCP on the switched ports of the RG, and leave DHCP on for the Wireless side of the RG, right?

 

Is that even possible? (My WHR allows this, but my WHR running dd-wrt has a LOT more function than the AT&T RG anyway). 

 

If I do that, and set the RG's internal IP to 10.0.2.1, and the WHR to 10.0.1.1, can the traffic hitting the external 99.x IP get routed correctly to those LAN machines plugged into the switch attached to one of the switch ports of the WHR?

Re: Configuring DMZPlus or port-forwarding for LAN access

11 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 9:15:06 AM
0
(0)
Expert

We have some limitations here that we have to work with because of the RG:

 

1. The RG doesn't support multihomed hosts, so you cannot point all the static IPs to the WHR, that won't work.

2. You cannot turn off DHCP on the RG.  In normal U-Verse service, DHCP is required for the TV Set-Top Boxes.  I know you don't have TV service, but the RG is set up for it and DHCP cannot be turned off.

 

I am fairly confident that we can get everything you need working properly without the WHR and without the static IPs.  The RG is flexible enough to configure that, but it will require several steps.  We can also do it with some or all of the static IPs, yor choice.

 

Alternatively, we can also set it up where your WHR forwards ports, but you will not be able to use your static IP block like that.  You will have to use the single public IP that is issued to the outside interface of the RG.

 

So you tell me what you want to do, and we'll set it up.

 

We have some limitations here that we have to work with because of the RG:

 

1. The RG doesn't support multihomed hosts, so you cannot point all the static IPs to the WHR, that won't work.

2. You cannot turn off DHCP on the RG.  In normal U-Verse service, DHCP is required for the TV Set-Top Boxes.  I know you don't have TV service, but the RG is set up for it and DHCP cannot be turned off.

 

I am fairly confident that we can get everything you need working properly without the WHR and without the static IPs.  The RG is flexible enough to configure that, but it will require several steps.  We can also do it with some or all of the static IPs, yor choice.

 

Alternatively, we can also set it up where your WHR forwards ports, but you will not be able to use your static IP block like that.  You will have to use the single public IP that is issued to the outside interface of the RG.

 

So you tell me what you want to do, and we'll set it up.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

12 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 9:47:56 AM
0
(0)
Teacher

Unless I can ssh into the RG and set some firewall rules manually (as I can with the WHR), then the WHR has to stay in place. There are simply things that can't be done with the RG, that the WHR handles beautifully.

 

To that end, I've attached the WAN port of the WHR to the back of the RG, and set the WHR to DMZPlus. 

 

The RG is configured with a local IP of 10.0.2.1

The WHR is configured with a local IP of 10.0.1.1

 

I've plugged my switch into the back of the WHR, and all LAN machines (also defined with 10.0.1.x addresses) are plugged into that switch. 

 

DHCP is enabled for the LAN ports on the WHR.

WLAN is disabled on the WHR. 

 

WLAN is enabled on the RG, giving out 10.0.2.10-10.0.2.30 addresses to wireless clients. 

 

Heres's the problem... when I'm a DHCP client with a 10.0.2.11 address connected to the RG over wireless, I can't see/ping/connect to anything on the local LAN (10.0.1.1, 10.0.1.4, etc.) They're invisible to me (yes, I've disabled blocking of ICMP echo on both RG and WHR). 

 

This is what I suspected would happen. Anything on 10.0.2.x can't talk to 10.0.1.x, however machines on 10.0.1.x CAN talk to clients on 10.0.2.x and out to the live Internet. 

 

Does the RG actively deny/block anything behind a DMZPlus connection by default? I mean, if I'm on 10.0.2.11 and attempt to ssh into 10.0.1.4, it just sits there, until it times out. 

 

If I plug my laptop into the back of the switch (or a PlugLink attached to that switch) and get a 10.0.1.37 DHCP address, I CAN ssh into those LAN machines, and I CAN ping 10.0.2.1, and I CAN get out to the live Internet. 

 

It seems I'm blocked from either side, depending on how I confgure these components.

 

Sigh.

 

 

Unless I can ssh into the RG and set some firewall rules manually (as I can with the WHR), then the WHR has to stay in place. There are simply things that can't be done with the RG, that the WHR handles beautifully.

 

To that end, I've attached the WAN port of the WHR to the back of the RG, and set the WHR to DMZPlus. 

 

The RG is configured with a local IP of 10.0.2.1

The WHR is configured with a local IP of 10.0.1.1

 

I've plugged my switch into the back of the WHR, and all LAN machines (also defined with 10.0.1.x addresses) are plugged into that switch. 

 

DHCP is enabled for the LAN ports on the WHR.

WLAN is disabled on the WHR. 

 

WLAN is enabled on the RG, giving out 10.0.2.10-10.0.2.30 addresses to wireless clients. 

 

Heres's the problem... when I'm a DHCP client with a 10.0.2.11 address connected to the RG over wireless, I can't see/ping/connect to anything on the local LAN (10.0.1.1, 10.0.1.4, etc.) They're invisible to me (yes, I've disabled blocking of ICMP echo on both RG and WHR). 

 

This is what I suspected would happen. Anything on 10.0.2.x can't talk to 10.0.1.x, however machines on 10.0.1.x CAN talk to clients on 10.0.2.x and out to the live Internet. 

 

Does the RG actively deny/block anything behind a DMZPlus connection by default? I mean, if I'm on 10.0.2.11 and attempt to ssh into 10.0.1.4, it just sits there, until it times out. 

 

If I plug my laptop into the back of the switch (or a PlugLink attached to that switch) and get a 10.0.1.37 DHCP address, I CAN ssh into those LAN machines, and I CAN ping 10.0.2.1, and I CAN get out to the live Internet. 

 

It seems I'm blocked from either side, depending on how I confgure these components.

 

Sigh.

 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

13 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 9:55:21 AM
0
(0)
Expert

OK, I asked earlier if you were doing anything special with the WHR, to which you replied no, only firewalling and port forwarding.

 

Now you're saying that you would need to SSH into the RG because "there are simply things that can't be done with the RG, that the WHR handles beautifully".

 

What things?  Why do you need SSH into the RG?

 

Now you've reconfigured your network to have all your clients behind the WHR instead of attached to the RG as you described earlier.

 

 

Look, I can't help you if we don't follow a plan here.  I can help you if you tell me exactly what you need.  You are making judgments and suppositions about the RG that you don't actually know.

 

I am well aware of the problem you're having with RG wireless clients unable to talk to computers behind the WHR.  I would have prevented you from having to discover that on your own if you would just work with me.

 

OK, I asked earlier if you were doing anything special with the WHR, to which you replied no, only firewalling and port forwarding.

 

Now you're saying that you would need to SSH into the RG because "there are simply things that can't be done with the RG, that the WHR handles beautifully".

 

What things?  Why do you need SSH into the RG?

 

Now you've reconfigured your network to have all your clients behind the WHR instead of attached to the RG as you described earlier.

 

 

Look, I can't help you if we don't follow a plan here.  I can help you if you tell me exactly what you need.  You are making judgments and suppositions about the RG that you don't actually know.

 

I am well aware of the problem you're having with RG wireless clients unable to talk to computers behind the WHR.  I would have prevented you from having to discover that on your own if you would just work with me.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

14 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 10:06:15 AM
0
(0)
Teacher

There aren't enough ports on the back of the RG to handle my clients behind it, which is why I need the WHR and the switch to do that, and the firewalling on the RG is very basic, and doesn't allow much flexibility there.

 

For example, how do I specify a user-defined firewall rule that allows both TCP and UDP? (for example, bind). With the RG, it only has radio buttons, and I can only do one or the other (though, I probably could create a bind_tcp and enable TCP, and a bind_udp and enable UDP as two separate rulesets).

 

I also can't specify a range of allowed IPs that can use that application (externally), while denying others outside that range. 

 

The WHR handles a lot more granular firewalling and routing than the RG does, which is why I need to use that instead of the RG as the primary router.

 

My configuration must allow the following at the very least: 

 

1. WHR doing all port-forwarding and firewalling for all LAN clients

2. All LAN clients connect to WHR via the switch, not RG 

 

All public traffic coming into the public IP block I have, needs to be routed (via the WHR) to those LAN clients, not routed via the RG to those LAN clients.

 

At this point, I managed to get the port-forwarding "working", from public Internet to the LAN clients, but I can only do that if I'm physically attached to the same LAN segment as the WHR. I can't configure the WHR (on 10.0.1.1) from the RG's DHCP pool (on 10.0.2.x)

 

10.0.1.x can 

 

How do I define a static VLAN on the RG between 10.0.2.1 and 10.0.1.1, so clients on either side can talk to clients on the other side? 

 

At this point, I could probably just disable WLAN on the RG entirely, and use my WHR's WLAN (again, more flexibliity in the configuration there; I can set the CPU speed of the device, tx/rx power, etc. which I can't do with the RG), and allow any and all LAN and WLAN clients to just exist on the 10.0.1.x segment, which CAN talk to the 10.0.2.1 RG and configure it... 

 

Unless you've got some ideas, I guess I'll try that next.

 

I do appreciate your help, but I've been hammering on this now for 3 solid days, without any real success. :smileysad:

 

There aren't enough ports on the back of the RG to handle my clients behind it, which is why I need the WHR and the switch to do that, and the firewalling on the RG is very basic, and doesn't allow much flexibility there.

 

For example, how do I specify a user-defined firewall rule that allows both TCP and UDP? (for example, bind). With the RG, it only has radio buttons, and I can only do one or the other (though, I probably could create a bind_tcp and enable TCP, and a bind_udp and enable UDP as two separate rulesets).

 

I also can't specify a range of allowed IPs that can use that application (externally), while denying others outside that range. 

 

The WHR handles a lot more granular firewalling and routing than the RG does, which is why I need to use that instead of the RG as the primary router.

 

My configuration must allow the following at the very least: 

 

1. WHR doing all port-forwarding and firewalling for all LAN clients

2. All LAN clients connect to WHR via the switch, not RG 

 

All public traffic coming into the public IP block I have, needs to be routed (via the WHR) to those LAN clients, not routed via the RG to those LAN clients.

 

At this point, I managed to get the port-forwarding "working", from public Internet to the LAN clients, but I can only do that if I'm physically attached to the same LAN segment as the WHR. I can't configure the WHR (on 10.0.1.1) from the RG's DHCP pool (on 10.0.2.x)

 

10.0.1.x can 

 

How do I define a static VLAN on the RG between 10.0.2.1 and 10.0.1.1, so clients on either side can talk to clients on the other side? 

 

At this point, I could probably just disable WLAN on the RG entirely, and use my WHR's WLAN (again, more flexibliity in the configuration there; I can set the CPU speed of the device, tx/rx power, etc. which I can't do with the RG), and allow any and all LAN and WLAN clients to just exist on the 10.0.1.x segment, which CAN talk to the 10.0.2.1 RG and configure it... 

 

Unless you've got some ideas, I guess I'll try that next.

 

I do appreciate your help, but I've been hammering on this now for 3 solid days, without any real success. :smileysad:

 

Re: Configuring DMZPlus or port-forwarding for LAN access

15 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 11:14:32 AM
0
(0)
Expert

setuid wrote:

There aren't enough ports on the back of the RG to handle my clients behind it, which is why I need the WHR and the switch to do that, and the firewalling on the RG is very basic, and doesn't allow much flexibility there.

 

For example, how do I specify a user-defined firewall rule that allows both TCP and UDP? (for example, bind). With the RG, it only has radio buttons, and I can only do one or the other (though, I probably could create a bind_tcp and enable TCP, and a bind_udp and enable UDP as two separate rulesets).

 

I also can't specify a range of allowed IPs that can use that application (externally), while denying others outside that range. 

 

The WHR handles a lot more granular firewalling and routing than the RG does, which is why I need to use that instead of the RG as the primary router.


 

As I tried to explain, all of that is not true (with the exception of the specified range of inbound IPs).

 

The RG allows many firewall rules, including very complex rules such as the necessary ports for bind, http, etc.

 

If you're short on physical ports, we can fix that quite easily with a few changes to your WHR.

 

But you have some mutually incompatible requirements here:

 

  • You cannot use the WHR as a router AND use your static IPs.  No ifs, ands, or buts.  It doesn't work.  Forget it.  You can use the WHR and only use 1 IP on its outside interface OR you can use your static IPs without the WHR doing any routing.  Which do you want?
  • Which is more important -- using the static IPs or configuring the firewall to filter inbound sessions by IP address?  Because you need the WHR to route in order to set that up, and you can't use it with your static IPs. 


You MUST answer those questions before we can decide on a topology and configuration that's going to work for you.

 


setuid wrote:

There aren't enough ports on the back of the RG to handle my clients behind it, which is why I need the WHR and the switch to do that, and the firewalling on the RG is very basic, and doesn't allow much flexibility there.

 

For example, how do I specify a user-defined firewall rule that allows both TCP and UDP? (for example, bind). With the RG, it only has radio buttons, and I can only do one or the other (though, I probably could create a bind_tcp and enable TCP, and a bind_udp and enable UDP as two separate rulesets).

 

I also can't specify a range of allowed IPs that can use that application (externally), while denying others outside that range. 

 

The WHR handles a lot more granular firewalling and routing than the RG does, which is why I need to use that instead of the RG as the primary router.


 

As I tried to explain, all of that is not true (with the exception of the specified range of inbound IPs).

 

The RG allows many firewall rules, including very complex rules such as the necessary ports for bind, http, etc.

 

If you're short on physical ports, we can fix that quite easily with a few changes to your WHR.

 

But you have some mutually incompatible requirements here:

 

  • You cannot use the WHR as a router AND use your static IPs.  No ifs, ands, or buts.  It doesn't work.  Forget it.  You can use the WHR and only use 1 IP on its outside interface OR you can use your static IPs without the WHR doing any routing.  Which do you want?
  • Which is more important -- using the static IPs or configuring the firewall to filter inbound sessions by IP address?  Because you need the WHR to route in order to set that up, and you can't use it with your static IPs. 


You MUST answer those questions before we can decide on a topology and configuration that's going to work for you.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

16 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 1:00:56 PM
0
(0)
Teacher

Let me back up a bit and give you some context, which may help you understand the situation.

 

I'm ejecting my current hosting provider. They've been doing some unscrupulous things to the hardware I lease from them (not a VPS, I lease a physical box, and manage the OS/configuration/etc. myself; they're supposed to be hands-off). 

 

I've been doing hosting myself for about 12 years, and only recently pushed my services up to a public hosting provider. Big mistake. 

 

So I run web, mail, code repositories and other services in support of OSS developers and OSS projects on my own hardware, servers and racks. 

 

The only reason I need more than one single public IP, is to support some of the SSL sites I manage for these developers (webmail is behind SSL, imap, DSPAM gateway, etc.) Otherwise I could do everything with one single IP, and be done with it. https doesn't like that, because certs can't be validated if the origin doesn't match (that's just the way SSL works). 

 

Right now, I have all of my servers behind the public network connection configured with 10.0.1.x static addressing. This can not change.

 

The block of IPs that I am leasing from AT&T through the U-Verse package contains the following range: 

 

75.54.193.185

75.54.193.186

75.54.193.187

75.54.193.188

75.54.193.189

75.54.193.190

 

These are my usable IPs, with the last one being defined in the RG as the "Public Routed Subinterface" (whatever that is)

 

Ideally, traffic should hit one of those IPs as the "main" IP (the one where all non-SSL traffic is directed via DNS), and the others should be IPs dedicated to servicing the SSL services (https, imaps, ldaps).

 

How do I get these addresses properly routed to the physical servers on the local LAN (on the 10.0.1.x segment), using whatever combination of RG and WHR is required? 

 

I need to be able to access any and all machines from all of the wireless DHCP management clients on the inside of this network segment. 

 

Right now, I have the RG at 10.0.2.1, with the WHR connected to the back of it on the WHR's WAN port. There is a 10-port switch plugged into the back of the WHR, where all of the physical servers are currently plugged in. I disabled WLAN on the RG, and enabled it on the WHR, which now gives me access to LAN, WLAN and Internet. The WHR is configured as the only DMZPlus node on the segment.

 

If I configure port-forwarding rules on the WHR to allow traffic from the public WAN IP to the local 10.0.1.x clients, this now works. This is what I was trying to achieve from the start, only I was focusing on getting the RG to do it, and found that impossible, so I configured the WHR to do it instead, which was a simple drop-in. 

 

Now that the port-forwarding appears to work, how do I get the dedicated SSL IPs routed to the right internal machines to allow the SSL services to function? That's where I'm at now. 

 

Ideas?

 

Let me back up a bit and give you some context, which may help you understand the situation.

 

I'm ejecting my current hosting provider. They've been doing some unscrupulous things to the hardware I lease from them (not a VPS, I lease a physical box, and manage the OS/configuration/etc. myself; they're supposed to be hands-off). 

 

I've been doing hosting myself for about 12 years, and only recently pushed my services up to a public hosting provider. Big mistake. 

 

So I run web, mail, code repositories and other services in support of OSS developers and OSS projects on my own hardware, servers and racks. 

 

The only reason I need more than one single public IP, is to support some of the SSL sites I manage for these developers (webmail is behind SSL, imap, DSPAM gateway, etc.) Otherwise I could do everything with one single IP, and be done with it. https doesn't like that, because certs can't be validated if the origin doesn't match (that's just the way SSL works). 

 

Right now, I have all of my servers behind the public network connection configured with 10.0.1.x static addressing. This can not change.

 

The block of IPs that I am leasing from AT&T through the U-Verse package contains the following range: 

 

75.54.193.185

75.54.193.186

75.54.193.187

75.54.193.188

75.54.193.189

75.54.193.190

 

These are my usable IPs, with the last one being defined in the RG as the "Public Routed Subinterface" (whatever that is)

 

Ideally, traffic should hit one of those IPs as the "main" IP (the one where all non-SSL traffic is directed via DNS), and the others should be IPs dedicated to servicing the SSL services (https, imaps, ldaps).

 

How do I get these addresses properly routed to the physical servers on the local LAN (on the 10.0.1.x segment), using whatever combination of RG and WHR is required? 

 

I need to be able to access any and all machines from all of the wireless DHCP management clients on the inside of this network segment. 

 

Right now, I have the RG at 10.0.2.1, with the WHR connected to the back of it on the WHR's WAN port. There is a 10-port switch plugged into the back of the WHR, where all of the physical servers are currently plugged in. I disabled WLAN on the RG, and enabled it on the WHR, which now gives me access to LAN, WLAN and Internet. The WHR is configured as the only DMZPlus node on the segment.

 

If I configure port-forwarding rules on the WHR to allow traffic from the public WAN IP to the local 10.0.1.x clients, this now works. This is what I was trying to achieve from the start, only I was focusing on getting the RG to do it, and found that impossible, so I configured the WHR to do it instead, which was a simple drop-in. 

 

Now that the port-forwarding appears to work, how do I get the dedicated SSL IPs routed to the right internal machines to allow the SSL services to function? That's where I'm at now. 

 

Ideas?

 

Re: Configuring DMZPlus or port-forwarding for LAN access

17 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 1:35:37 PM
0
(0)
Expert

OK, I understand things a bit more now.

 

You're in a bit of a dilemma.  It's true that the RG isn't as flexible as it needs to be for this kind of configuration, but I can tell you how to get it to work but only under the following conditions:

 

  • There will be no way to filter incoming requests to be allowed only from a certain IP range.  The RG doesn't have that kind of functionality.  You may be able to add that filter to your server(s) if you use a firewall on them.
  • I can't do this with your servers assigned statically to private IP addresses in the 10.0.1.x range.  If a server needs to use a public IP, the public IP actually has to be assigned on the server.  It will still be protected by the RG's firewall except for the firewall entries we will make.



If you can live with these two restrictions, you can do it.

 

In this situation you will probably end up with some servers on the public IPs and some on private IPs.  They can still communicate, but all of their communication will go through the RG.  There are a few ways around this if there are other considerations:

 

1. You can add a 2nd NIC to the servers with public IPs, give the 2nd NIC a private IP and no default gateway.

2. You can purchase a larger block of static IPs (I think you can get a block of 16, with 13 usable) and put public IPs on all machines.

 

 

OK, I understand things a bit more now.

 

You're in a bit of a dilemma.  It's true that the RG isn't as flexible as it needs to be for this kind of configuration, but I can tell you how to get it to work but only under the following conditions:

 

  • There will be no way to filter incoming requests to be allowed only from a certain IP range.  The RG doesn't have that kind of functionality.  You may be able to add that filter to your server(s) if you use a firewall on them.
  • I can't do this with your servers assigned statically to private IP addresses in the 10.0.1.x range.  If a server needs to use a public IP, the public IP actually has to be assigned on the server.  It will still be protected by the RG's firewall except for the firewall entries we will make.



If you can live with these two restrictions, you can do it.

 

In this situation you will probably end up with some servers on the public IPs and some on private IPs.  They can still communicate, but all of their communication will go through the RG.  There are a few ways around this if there are other considerations:

 

1. You can add a 2nd NIC to the servers with public IPs, give the 2nd NIC a private IP and no default gateway.

2. You can purchase a larger block of static IPs (I think you can get a block of 16, with 13 usable) and put public IPs on all machines.

 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

18 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 28, 2009 11:13:58 PM
0
(0)
Teacher

After doing some hours of reading, it seems the RG is not physically capable of doing what I need... which begs the question: Why does AT&T sell blocks of static IPs, if the RG can only ever handle one of them?

 

From what I've read, the RG can't be set to bridged mode, passing all traffic to another device plugged into the same LAN (my WHR router running dd-wrt in my case).

 

The RG also can't map a local static IP to a public static IP in the "Edit Address Allocation" page. It requires that the machines be DHCP clients of the RG-provisioned DHCP pool; an unreasonable requirement.

 

The RG also can't map multiple public IPs to one local IP (in the case of an Apache webserver running more than one SSL website. HUGE blocker. Since it identifies each client by MAC address, multiple VIPs will share the same MAC, so they won't show up as separate items in the "Edit Address Allocation" page.

 

There are apparently a few hundred people who are trying to do the same thing, 0% of them having achieved any sort of success with it. 

 

I can't configure my LAN-based servers to DHCP, and let the RG maintain the DHCP reservation for those machines.That seems to be the only way the RG can map one private DHCP address to one public static IP from my block of IPs. 

 

So what are other people doing, that these devices and various configurations aren't allowing? Is there a way to just rip the RG out and replace it with a proper router that can do this? It seems the only limitation is the RJ11 requirement, which most capable routers lack.

 

My need is still very basic:

  1. Get the RG to bridge all public IP's traffic onto its LAN ports. On one of those LAN ports, is my WHR, happily waiting to NAT and route that traffic to its respective local LAN clients.
  2. Ensure that all local LAN machines remain statically defined with their 10.0.1.x addresses.
  3. Ensure that all WLAN clients can connect to and communicate with Internet and LAN clients

Nothing magical there, but apparently too much voodoo for the RG to handle.

 

Is there a better/higher-level RG that I should be using instead, which does allow this capability?

 

 

Message Edited by setuid on 12-29-2009 02:15 AM

After doing some hours of reading, it seems the RG is not physically capable of doing what I need... which begs the question: Why does AT&T sell blocks of static IPs, if the RG can only ever handle one of them?

 

From what I've read, the RG can't be set to bridged mode, passing all traffic to another device plugged into the same LAN (my WHR router running dd-wrt in my case).

 

The RG also can't map a local static IP to a public static IP in the "Edit Address Allocation" page. It requires that the machines be DHCP clients of the RG-provisioned DHCP pool; an unreasonable requirement.

 

The RG also can't map multiple public IPs to one local IP (in the case of an Apache webserver running more than one SSL website. HUGE blocker. Since it identifies each client by MAC address, multiple VIPs will share the same MAC, so they won't show up as separate items in the "Edit Address Allocation" page.

 

There are apparently a few hundred people who are trying to do the same thing, 0% of them having achieved any sort of success with it. 

 

I can't configure my LAN-based servers to DHCP, and let the RG maintain the DHCP reservation for those machines.That seems to be the only way the RG can map one private DHCP address to one public static IP from my block of IPs. 

 

So what are other people doing, that these devices and various configurations aren't allowing? Is there a way to just rip the RG out and replace it with a proper router that can do this? It seems the only limitation is the RJ11 requirement, which most capable routers lack.

 

My need is still very basic:

  1. Get the RG to bridge all public IP's traffic onto its LAN ports. On one of those LAN ports, is my WHR, happily waiting to NAT and route that traffic to its respective local LAN clients.
  2. Ensure that all local LAN machines remain statically defined with their 10.0.1.x addresses.
  3. Ensure that all WLAN clients can connect to and communicate with Internet and LAN clients

Nothing magical there, but apparently too much voodoo for the RG to handle.

 

Is there a better/higher-level RG that I should be using instead, which does allow this capability?

 

 

Message Edited by setuid on 12-29-2009 02:15 AM

Re: Configuring DMZPlus or port-forwarding for LAN access

19 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 9:00:53 AM
0
(0)
Teacher

Still nothing, still nowhere.

 

I removed the WHR entirely from the picture, and now only have the 10-port switch plugged into the back of the RG, with all LAN machines (and a PlugLink adapter) hanging off of that.

 

I've enabled WLAN on the RG, which allows my laptops, BlackBerry, etc. to get on the LAN, and from there, I can see and log into my LAN machines (.4, .5, etc.)

 

The RG is 10.0.1.1, giving out DHCP addresses on 10.0.1.10-10.0.1.30. 

 

But I still can't assign any of those LAN machines to any of the external static IP addresses. The only address the RG will let me give the router is the 75.54.193.190/255.255.255.248 address. The IPs that show up in the right-side dropdown when I try to edit the address allocation are the 75.54.193.184-75.54.193.189 static IPs. 

 

When I try to assign 10.0.1.4 to 75.54.193.184, I get the error message of: 

 

"For the public routed subinterface only WAN IP mapping is allowed."

 

How am I supposed to create a route from the internal LAN machines to the external static IPs, if it won't let me assign them here? 

 

Is there a commandline interface to this that I can use instead?

 

Perhaps some other "hidden" GUI features pages that has this?

 

Maybe another version of the firmware?

 

HELP! :smileysad:

 

Still nothing, still nowhere.

 

I removed the WHR entirely from the picture, and now only have the 10-port switch plugged into the back of the RG, with all LAN machines (and a PlugLink adapter) hanging off of that.

 

I've enabled WLAN on the RG, which allows my laptops, BlackBerry, etc. to get on the LAN, and from there, I can see and log into my LAN machines (.4, .5, etc.)

 

The RG is 10.0.1.1, giving out DHCP addresses on 10.0.1.10-10.0.1.30. 

 

But I still can't assign any of those LAN machines to any of the external static IP addresses. The only address the RG will let me give the router is the 75.54.193.190/255.255.255.248 address. The IPs that show up in the right-side dropdown when I try to edit the address allocation are the 75.54.193.184-75.54.193.189 static IPs. 

 

When I try to assign 10.0.1.4 to 75.54.193.184, I get the error message of: 

 

"For the public routed subinterface only WAN IP mapping is allowed."

 

How am I supposed to create a route from the internal LAN machines to the external static IPs, if it won't let me assign them here? 

 

Is there a commandline interface to this that I can use instead?

 

Perhaps some other "hidden" GUI features pages that has this?

 

Maybe another version of the firmware?

 

HELP! :smileysad:

 

Re: Configuring DMZPlus or port-forwarding for LAN access

20 of 37 (931 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 10:00:53 AM
0
(0)
Expert

I have repeatedly tried to help you here and you still won't answer any of my questions.

 

For the fourth time: You are trying to do things that the RG won't do.

 

I have asked you on multiple occasions if there are particular compromises that you can live with, you haven't answered.  No one can tell you the procedure to do what you want until you agree to the compromises proposed.

 

Once again:

 

  • Are you OK with not having inbound filtering by source IP address?
  • Can you assign the public IPs statically to the servers directly instead of using private IPs?
  • Can you deal with only 1 public IP per machine?


Unless you can respond: Yes, Yes, Yes, no one can help you.

 

If these compromises are not acceptable, then you should seek a different provider that has a more flexible internet solution.

 

I have repeatedly tried to help you here and you still won't answer any of my questions.

 

For the fourth time: You are trying to do things that the RG won't do.

 

I have asked you on multiple occasions if there are particular compromises that you can live with, you haven't answered.  No one can tell you the procedure to do what you want until you agree to the compromises proposed.

 

Once again:

 

  • Are you OK with not having inbound filtering by source IP address?
  • Can you assign the public IPs statically to the servers directly instead of using private IPs?
  • Can you deal with only 1 public IP per machine?


Unless you can respond: Yes, Yes, Yes, no one can help you.

 

If these compromises are not acceptable, then you should seek a different provider that has a more flexible internet solution.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

21 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 10:06:27 AM
0
(0)
Scholar

The RG support multiple public static IP blocks just fine. You are just trying to use it as a bridged VDSL MODEM which it is not and the RG does not support a dumb bridge mode. This has been covered multiple times. The 2Wire is required for authentication for your U-verse connection.

 

Note: The 2Wire firewall only allows traffic for a public network IP address to be directed to a local LAN device with the same public network IP address. That is, except for traffic sent to the single broadband IP address assigned to the router (your 99.16.211.3 address) and shared through NAPT, traffic sent to other specific broadband IP addresses associated with the connection cannot be directed to local LAN devices that may be using private IP addresses.

 

In a previous post you listed the following services: 


setuid wrote:

 

2. Please list the servers and services on each that you need to have accessible from the internet.

 

smtp (sendmail on 25), dns (using bind9 on 53), web (apache on 80/443), ssh (port-knocked on high ports), imap/imaps (dovecot on 143/993), ldap/ldaps (OpenLDAP on 389/636) cvs (2401), and a handful of others.


While it is recommended that you use one of the thee prefered modes that support the use of the 2Wire "Edit Address Allocation" function to map DHCP / Private IP addresses to your Public Network block. You do not have to use DHCP for the static IP assignments, if you just hard code one of the public routed IPs from the public subnet the RG will detect it's use and create the mapping in the RG.

 

For devices using the Public Network addresses, simply configure the device to use one of your public IP addresses (subnet mask and default gateway(the last address in your public block...) as assigned by the U-verse.

 

Public Routed Subinterface    
Router Address: 75.54.193.190 
Subnet Mask:    255.255.255.248

 

The gateway will automatically detect the usage of a broadband IP address on the LAN network and correctly route the return traffic to the appropriate LAN device. Once a broadband IP address has been detected by the gateway as being statically coded on the device, its entry in the Address Allocation page will no longer be displayed.

 

Now just configure the 2Wire firewall rules since by default the Firewall is still protecting even your multiple public network addresses. Yes this is different then how other routers treat public addresses or "DMZ" addressed devices. Yes you can configure a single firewall rule that covers both TCP and UDP traffic and even multiple port ranges. Just click the Add a new user-defined application link on the "Edit Firewall Settings" page. Just remember the note above concerning the mapping for traffic from a Public IP Address. You can't map ports from the public block to private IP addresses by using the Firewall. Public block IP traffic has to go to a host that has the same public block address.

 

If you want to use the multiple static IP blocks using another secondary router (hardware device or software based (Multi-homed Unix machine examples have been used with some success)) you have to use some complex configurations that are error prone, will often fail or you can just use the RG the way it was designed to be used with U-verse.

 

Dave

The RG support multiple public static IP blocks just fine. You are just trying to use it as a bridged VDSL MODEM which it is not and the RG does not support a dumb bridge mode. This has been covered multiple times. The 2Wire is required for authentication for your U-verse connection.

 

Note: The 2Wire firewall only allows traffic for a public network IP address to be directed to a local LAN device with the same public network IP address. That is, except for traffic sent to the single broadband IP address assigned to the router (your 99.16.211.3 address) and shared through NAPT, traffic sent to other specific broadband IP addresses associated with the connection cannot be directed to local LAN devices that may be using private IP addresses.

 

In a previous post you listed the following services: 


setuid wrote:

 

2. Please list the servers and services on each that you need to have accessible from the internet.

 

smtp (sendmail on 25), dns (using bind9 on 53), web (apache on 80/443), ssh (port-knocked on high ports), imap/imaps (dovecot on 143/993), ldap/ldaps (OpenLDAP on 389/636) cvs (2401), and a handful of others.


While it is recommended that you use one of the thee prefered modes that support the use of the 2Wire "Edit Address Allocation" function to map DHCP / Private IP addresses to your Public Network block. You do not have to use DHCP for the static IP assignments, if you just hard code one of the public routed IPs from the public subnet the RG will detect it's use and create the mapping in the RG.

 

For devices using the Public Network addresses, simply configure the device to use one of your public IP addresses (subnet mask and default gateway(the last address in your public block...) as assigned by the U-verse.

 

Public Routed Subinterface    
Router Address: 75.54.193.190 
Subnet Mask:    255.255.255.248

 

The gateway will automatically detect the usage of a broadband IP address on the LAN network and correctly route the return traffic to the appropriate LAN device. Once a broadband IP address has been detected by the gateway as being statically coded on the device, its entry in the Address Allocation page will no longer be displayed.

 

Now just configure the 2Wire firewall rules since by default the Firewall is still protecting even your multiple public network addresses. Yes this is different then how other routers treat public addresses or "DMZ" addressed devices. Yes you can configure a single firewall rule that covers both TCP and UDP traffic and even multiple port ranges. Just click the Add a new user-defined application link on the "Edit Firewall Settings" page. Just remember the note above concerning the mapping for traffic from a Public IP Address. You can't map ports from the public block to private IP addresses by using the Firewall. Public block IP traffic has to go to a host that has the same public block address.

 

If you want to use the multiple static IP blocks using another secondary router (hardware device or software based (Multi-homed Unix machine examples have been used with some success)) you have to use some complex configurations that are error prone, will often fail or you can just use the RG the way it was designed to be used with U-verse.

 

Dave

Re: Configuring DMZPlus or port-forwarding for LAN access

22 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 11:06:31 AM
0
(0)
Teacher

Wait, what? So the RG can't do NAT between the public IP and a private IP on my LAN? I have to actually reconfigure all LAN machines to have public, Internet-facing, routable addresses?

 

That means I can't access them from my local LAN, and I'm going out the RG and back in, to do backups and other administrative tasks on them.

 

That can't possibly be the solution they've implemented here. 

 

I'm going to try to set a second virtual address (eth0:1) on the same NIC as the private LAN address and see if the RG creates the mapping you're referring to.

 

Wait, what? So the RG can't do NAT between the public IP and a private IP on my LAN? I have to actually reconfigure all LAN machines to have public, Internet-facing, routable addresses?

 

That means I can't access them from my local LAN, and I'm going out the RG and back in, to do backups and other administrative tasks on them.

 

That can't possibly be the solution they've implemented here. 

 

I'm going to try to set a second virtual address (eth0:1) on the same NIC as the private LAN address and see if the RG creates the mapping you're referring to.

 

Re: Configuring DMZPlus or port-forwarding for LAN access

23 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 11:13:48 AM
0
(0)
Teacher

Nope, that doesn't work... sigh.

 

"For the public routed subinterface only WAN IP mapping is allowed."

 

 eth0     Link encap:Ethernet  HWaddr 00:0f:ea:61:43:d4  
          inet addr:10.0.1.5  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:eaff:fe61:43d4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1332134 errors:0 dropped:0 overruns:0 frame:0
          TX packets:747775 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1435655554 (1.3 GiB)  TX bytes:140122879 (133.6 MiB)
          Interrupt:23

 

eth0:1    Link encap:Ethernet  HWaddr 00:0f:ea:61:43:d4 
          inet addr:75.54.193.184  Bcast:75.54.193.191  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:23

 

Message Edited by setuid on 12-29-2009 02:15 PM

Nope, that doesn't work... sigh.

 

"For the public routed subinterface only WAN IP mapping is allowed."

 

 eth0     Link encap:Ethernet  HWaddr 00:0f:ea:61:43:d4  
          inet addr:10.0.1.5  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:eaff:fe61:43d4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1332134 errors:0 dropped:0 overruns:0 frame:0
          TX packets:747775 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1435655554 (1.3 GiB)  TX bytes:140122879 (133.6 MiB)
          Interrupt:23

 

eth0:1    Link encap:Ethernet  HWaddr 00:0f:ea:61:43:d4 
          inet addr:75.54.193.184  Bcast:75.54.193.191  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:23

 

Message Edited by setuid on 12-29-2009 02:15 PM

Re: Configuring DMZPlus or port-forwarding for LAN access

24 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 11:19:20 AM
0
(0)
Scholar

setuid wrote:

Wait, what? So the RG can't do NAT between the public IP and a private IP on my LAN? I have to actually reconfigure all LAN machines to have public, Internet-facing, routable addresses?

 

That means I can't access them from my local LAN, and I'm going out the RG and back in, to do backups and other administrative tasks on them.

 

That can't possibly be the solution they've implemented here. 

 

I'm going to try to set a second virtual address (eth0:1) on the same NIC as the private LAN address and see if the RG creates the mapping you're referring to.

 


 

The RG supports NAT for the single U-verse IP but not for each of your additional pubic IP block addresses as I indicated in my post. If you want to have a multi-homed addressing scheme to do admin or other private tasks, just assign addition IP addresses to your hosts that have the static public IP addresses that are outside of the private DHCP range used by the RG for the local LAN.

 

For example if you used 10.0.0.1 for the start of the DHCP pool, just in adddition to the static public IP address, assign a secondary private IP that is outside of this range example above and you could have the private addressing that you are trying for but this is not a good way to manage an IP network with multi-homing and multiple subnets on the same physical LAN segment.

 

Normally if you want to have an admin segment, you should setup a seperate physical LAN segment with dedicated Ethernet cards and any switches if needed. This creates a physical boundary and provides complete isolation so that you can protect your hosts corectly.

 

Dave


setuid wrote:

Wait, what? So the RG can't do NAT between the public IP and a private IP on my LAN? I have to actually reconfigure all LAN machines to have public, Internet-facing, routable addresses?

 

That means I can't access them from my local LAN, and I'm going out the RG and back in, to do backups and other administrative tasks on them.

 

That can't possibly be the solution they've implemented here. 

 

I'm going to try to set a second virtual address (eth0:1) on the same NIC as the private LAN address and see if the RG creates the mapping you're referring to.

 


 

The RG supports NAT for the single U-verse IP but not for each of your additional pubic IP block addresses as I indicated in my post. If you want to have a multi-homed addressing scheme to do admin or other private tasks, just assign addition IP addresses to your hosts that have the static public IP addresses that are outside of the private DHCP range used by the RG for the local LAN.

 

For example if you used 10.0.0.1 for the start of the DHCP pool, just in adddition to the static public IP address, assign a secondary private IP that is outside of this range example above and you could have the private addressing that you are trying for but this is not a good way to manage an IP network with multi-homing and multiple subnets on the same physical LAN segment.

 

Normally if you want to have an admin segment, you should setup a seperate physical LAN segment with dedicated Ethernet cards and any switches if needed. This creates a physical boundary and provides complete isolation so that you can protect your hosts corectly.

 

Dave

Re: Configuring DMZPlus or port-forwarding for LAN access

25 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 12:02:13 PM
0
(0)
Teacher

That makes zero sense... if I assign private, static addresses outside of the RG's static and DHCP pool (10.0.1.1-10.0.1.10 for static, 10.0.1.11-10.0.1.30 for DHCP in this case), then I still can't reach them, unless something routes the traffic from say 10.0.2.1 to 10.0.1.4. What exactly is supposed to do that routing?

 

Unless I've missed what you're suggesting. Also, there are some machines here that physcially can't have any additional NICs put into them, which is exactly why they're being NAT'd to the outside. Having to have a separate physical NIC for each IP address assigned to a machine is silly. If I have a machine with 20 IP addresses, the RG requires that I have 20 separate NIC installed? 

 

This is all turned on its head. This is not how routing or networking was designed to work. 

 

I also noticed that when I define a second, public, static IP address on the physical host (eth0: 10.0.1.5 and eth0:1 75.54.193.184 on the 10.0.1.5 machine), the RG blocks my ability to get to that machine's PUBLIC IP address in a browser, from the LAN side of the RG. They've seriously botched up the networking of the RG if that's the case. 

 

I'm trying to validate that the websites and services I'm relocating to live behind the U-Verse connection are functioning, but I can't, because the RG actively blocks that traffic from reaching them from the inside. 

 

For example, I'm on WLAN to the RG with a 10.0.1.12 DHCP address from the RG's provisioned DHCP pool. I can see and log into hosts 10.0.1.2, 10.0.1.4, 10.0.1.5 on my side of the LAN. http://10.0.1.5 works in a browser (obviously vhosts aren't routing correctly with that address though). 

 

When I attempt to visit  http://75.54.193.184 in a browser on this side of the LAN, it fails. Visiting any of the sites via hostname also fails (I have DNS sitting on the outside pointing to these physical IPs for these hosts. I manage my own DNS, and will be pulling that behind the U-Verse connection once I know this is all working correctly). 

 

I'm beginning to suspect that the RG was designed to have one AND ONLY ONE machine running behind it, visible to the live Internet, and that you're not supposed to be able to reach that machine's public IP from the private LAN side of the RG. 

 

Is this true?

 

 

 

That makes zero sense... if I assign private, static addresses outside of the RG's static and DHCP pool (10.0.1.1-10.0.1.10 for static, 10.0.1.11-10.0.1.30 for DHCP in this case), then I still can't reach them, unless something routes the traffic from say 10.0.2.1 to 10.0.1.4. What exactly is supposed to do that routing?

 

Unless I've missed what you're suggesting. Also, there are some machines here that physcially can't have any additional NICs put into them, which is exactly why they're being NAT'd to the outside. Having to have a separate physical NIC for each IP address assigned to a machine is silly. If I have a machine with 20 IP addresses, the RG requires that I have 20 separate NIC installed? 

 

This is all turned on its head. This is not how routing or networking was designed to work. 

 

I also noticed that when I define a second, public, static IP address on the physical host (eth0: 10.0.1.5 and eth0:1 75.54.193.184 on the 10.0.1.5 machine), the RG blocks my ability to get to that machine's PUBLIC IP address in a browser, from the LAN side of the RG. They've seriously botched up the networking of the RG if that's the case. 

 

I'm trying to validate that the websites and services I'm relocating to live behind the U-Verse connection are functioning, but I can't, because the RG actively blocks that traffic from reaching them from the inside. 

 

For example, I'm on WLAN to the RG with a 10.0.1.12 DHCP address from the RG's provisioned DHCP pool. I can see and log into hosts 10.0.1.2, 10.0.1.4, 10.0.1.5 on my side of the LAN. http://10.0.1.5 works in a browser (obviously vhosts aren't routing correctly with that address though). 

 

When I attempt to visit  http://75.54.193.184 in a browser on this side of the LAN, it fails. Visiting any of the sites via hostname also fails (I have DNS sitting on the outside pointing to these physical IPs for these hosts. I manage my own DNS, and will be pulling that behind the U-Verse connection once I know this is all working correctly). 

 

I'm beginning to suspect that the RG was designed to have one AND ONLY ONE machine running behind it, visible to the live Internet, and that you're not supposed to be able to reach that machine's public IP from the private LAN side of the RG. 

 

Is this true?

 

 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

26 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 12:33:13 PM
0
(0)
Teacher

(throwing up arms in defeat)

 

Ok, let's me just start from scratch. Again. 

 

Let's say I have 5 machines sitting on my internal LAN. Each of these has a 10.0.1.x address.

 

The RG is currently configured with a 10.0.1.1 address. 

 

The RG is currently configured to hand out DHCP to LAN/WLAN clients from 10.0.1.11 to 10.0.1.30. 

 

I have 5 public static IP addresses available to me, from 75.54.193.184 to 75.54.193.189. 

 

To begin migrating services (web first), I have taken machine 10.0.1.5, and added an additional IP on the same physical interface:  75.54.193.184.

 

I've configured DNS for the hostnames to point their web traffic to 75.54.193.184. 

 

In the RG, I can't change the "Address Allocation" for this host because it doesn't show up in the list. 

 

I just changed the default DHCP pool to "swallow up" the 10.0.1.3-10.0.1.10 pool (which I carved out for my static LAN allocations).

 

I tested this by setting the machine with the previously-static address of 10.0.1.4 to DHCP, and the RG assigned it 10.0.1.4 again anyway. I went to the "Edit Address Allocation" menu, and saw that it now lets me select 10.0.1.3-10.0.1.30 from the left-side dropdown and the public static addresses from the right-side dropdown.

 

I tried to map 10.0.1.4 to  75.54.193.185, and got the error of: 

 

"For the public routed subinterface only WAN IP mapping is allowed."

 

So it looks like if my machines are defined with static addresses, DHCP addresses or publicly routable Internet addresses, the RG still can't route traffic to or from them correctly. 

 

Seriously, how is this done? Are all of these configuration screens just a "demo" of how it would work if those features were actually enabled on the RG, but the RG can't actually perform those duties?

 

I'm clearly missing some voodoo here... 

 

 

 

(throwing up arms in defeat)

 

Ok, let's me just start from scratch. Again. 

 

Let's say I have 5 machines sitting on my internal LAN. Each of these has a 10.0.1.x address.

 

The RG is currently configured with a 10.0.1.1 address. 

 

The RG is currently configured to hand out DHCP to LAN/WLAN clients from 10.0.1.11 to 10.0.1.30. 

 

I have 5 public static IP addresses available to me, from 75.54.193.184 to 75.54.193.189. 

 

To begin migrating services (web first), I have taken machine 10.0.1.5, and added an additional IP on the same physical interface:  75.54.193.184.

 

I've configured DNS for the hostnames to point their web traffic to 75.54.193.184. 

 

In the RG, I can't change the "Address Allocation" for this host because it doesn't show up in the list. 

 

I just changed the default DHCP pool to "swallow up" the 10.0.1.3-10.0.1.10 pool (which I carved out for my static LAN allocations).

 

I tested this by setting the machine with the previously-static address of 10.0.1.4 to DHCP, and the RG assigned it 10.0.1.4 again anyway. I went to the "Edit Address Allocation" menu, and saw that it now lets me select 10.0.1.3-10.0.1.30 from the left-side dropdown and the public static addresses from the right-side dropdown.

 

I tried to map 10.0.1.4 to  75.54.193.185, and got the error of: 

 

"For the public routed subinterface only WAN IP mapping is allowed."

 

So it looks like if my machines are defined with static addresses, DHCP addresses or publicly routable Internet addresses, the RG still can't route traffic to or from them correctly. 

 

Seriously, how is this done? Are all of these configuration screens just a "demo" of how it would work if those features were actually enabled on the RG, but the RG can't actually perform those duties?

 

I'm clearly missing some voodoo here... 

 

 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

27 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 1:06:28 PM
0
(0)
Scholar

First, yes you missed my discussion about an admin LAN segment. For now let's focus on what you are trying to do based on your last post.

 

Let's start with the basics: The RG wants to manage it's device list based on the physical MAC address. If you try to use multiple IP addresses within the range of the RG DHCP scope it will fail. If you try to assign one of your Public block IP addresses along with one in the DHCP scope it will fail.

 

The RG is designed to managed a mix of Public and Private devices. The Public IP block is managed by the RG by creating a virtual connection and it used the MAC to manage the assignments. The RG provides a Single WAN address, your 99.16.211.3 address for U-verse and to use for NAT purposes. If you also purchase a block of public IP addresses they are designed to be just that and not a set of virtual routers with NAT support.

 

If you go to this page: http://10.0.1.x/xslt?PAGE=C06&THISPAGE=C01&NEXTPAGE=C06 where the last octet is the address you set in your RG.

 

Configure the Public Routed Inteface using the following from your previous post:

 

Public Routed Subinterface    
Router Address: 75.54.193.190 
Subnet Mask:    255.255.255.248

 

Now assign your web server one of your public IP block addresses, 75.54.193.184 for example. Please assign it directly as a static IP and not by using a private IP and then trying to map it using the RG. Restart the interface on this host and then access something like google from this host, once this traffic passes the RG, the RG will add this device it's list and it will now route basic inbound traffic for 75.54.193.184 correctly.Again by default the Firewall will still be active even for this device, we will cover that after you get the test traffic flowing.

 

Let us know when this works, this is the first step.

 

Dave

 

Edit to add comment about assigning the public IP directly on the host and not via the RG.

Message Edited by dave006 on 12-29-2009 01:11 PM

First, yes you missed my discussion about an admin LAN segment. For now let's focus on what you are trying to do based on your last post.

 

Let's start with the basics: The RG wants to manage it's device list based on the physical MAC address. If you try to use multiple IP addresses within the range of the RG DHCP scope it will fail. If you try to assign one of your Public block IP addresses along with one in the DHCP scope it will fail.

 

The RG is designed to managed a mix of Public and Private devices. The Public IP block is managed by the RG by creating a virtual connection and it used the MAC to manage the assignments. The RG provides a Single WAN address, your 99.16.211.3 address for U-verse and to use for NAT purposes. If you also purchase a block of public IP addresses they are designed to be just that and not a set of virtual routers with NAT support.

 

If you go to this page: http://10.0.1.x/xslt?PAGE=C06&THISPAGE=C01&NEXTPAGE=C06 where the last octet is the address you set in your RG.

 

Configure the Public Routed Inteface using the following from your previous post:

 

Public Routed Subinterface    
Router Address: 75.54.193.190 
Subnet Mask:    255.255.255.248

 

Now assign your web server one of your public IP block addresses, 75.54.193.184 for example. Please assign it directly as a static IP and not by using a private IP and then trying to map it using the RG. Restart the interface on this host and then access something like google from this host, once this traffic passes the RG, the RG will add this device it's list and it will now route basic inbound traffic for 75.54.193.184 correctly.Again by default the Firewall will still be active even for this device, we will cover that after you get the test traffic flowing.

 

Let us know when this works, this is the first step.

 

Dave

 

Edit to add comment about assigning the public IP directly on the host and not via the RG.

Message Edited by dave006 on 12-29-2009 01:11 PM

Re: Configuring DMZPlus or port-forwarding for LAN access

28 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 3:32:25 PM
0
(0)
Teacher

I tried what you've suggested, statically assigning two of the public IP addresses to two of my servers (thank god I have physical access, because the RG blocks everything going to them from the LAN side once you do this).

 

I did the following: 

 

allow-hotplug eth0
iface eth0 inet static
        address 75.54.193.185

        netmask 255.255.255.248

        # this gateway is odd, but this is what the

        # RG sets when you use DHCP for this address 

        gateway 0.0.0.0

 

auto eth0:1
iface eth0:1 inet static

        address 10.0.1.5
        netmask 255.255.255.0

        gateway 10.0.1.1

 

When I reboot these machines using this config, it takes about 40 minutes each before the RG sees them to allocate addresses (even after generating network traffic on the segment to wake the RG up).

 

The RG still does not let me route traffic from the public Internet into these machines by mapping the addresses. If you define anything as static, you can't configure any mappings for it using the RG, which is ludicrous.

 

Configuring servers with DHCP addresses is flat-out wrong, and I can't even reserve statics in the DHCP pool, nor can I release those back to the pool for the RG to reuse correctly. 

 

What should I try next? 

 

Message Edited by setuid on 12-29-2009 06:35 PM

I tried what you've suggested, statically assigning two of the public IP addresses to two of my servers (thank god I have physical access, because the RG blocks everything going to them from the LAN side once you do this).

 

I did the following: 

 

allow-hotplug eth0
iface eth0 inet static
        address 75.54.193.185

        netmask 255.255.255.248

        # this gateway is odd, but this is what the

        # RG sets when you use DHCP for this address 

        gateway 0.0.0.0

 

auto eth0:1
iface eth0:1 inet static

        address 10.0.1.5
        netmask 255.255.255.0

        gateway 10.0.1.1

 

When I reboot these machines using this config, it takes about 40 minutes each before the RG sees them to allocate addresses (even after generating network traffic on the segment to wake the RG up).

 

The RG still does not let me route traffic from the public Internet into these machines by mapping the addresses. If you define anything as static, you can't configure any mappings for it using the RG, which is ludicrous.

 

Configuring servers with DHCP addresses is flat-out wrong, and I can't even reserve statics in the DHCP pool, nor can I release those back to the pool for the RG to reuse correctly. 

 

What should I try next? 

 

Message Edited by setuid on 12-29-2009 06:35 PM

Re: Configuring DMZPlus or port-forwarding for LAN access

29 of 37 (787 Views)
0
(0)
  • Rate this reply
View profile
Dec 29, 2009 3:33:45 PM
0
(0)
Teacher

Oh, I also spent about 2 hours on the phone with AT&T support, and they escalated it, but still nobody has any idea how to do this.

 

Seriously? They let you buy blocks of static IPs, but nobody within AT&T knows how to configure them? That's just laughable.

 

I've been at this now for 4 days, and haven't come a micron closer to any success. 

 

Oh, I also spent about 2 hours on the phone with AT&T support, and they escalated it, but still nobody has any idea how to do this.

 

Seriously? They let you buy blocks of static IPs, but nobody within AT&T knows how to configure them? That's just laughable.

 

I've been at this now for 4 days, and haven't come a micron closer to any success. 

 

Re: Configuring DMZPlus or port-forwarding for LAN access

30 of 37 (787 Views)
Advanced
You must be signed in to add attachments
Share this post
Share this post