AT&T U-verse
Migrating from AT&T DSL service
to AT&T U-verse service.
This document is intended as a guide for understanding differences between
the two services and specifically some pointers on how to configure your
new U-verse Remote Gateway to best fit your previous DSL service.
Two particular subjects covered will be the migrations for Static IP service
and from Bridge Mode configurations on DSL.
Page 1
Some of the Differences
While there are quite a few differences overall between the two services, from the technology to the topology we will cover some of them which can in
one way or another more commonly impact you the customer.
•
Various means of delivering the “last mile” of service. With your DSL service it is almost all ADSL technology. With AT&T U-verse there are various
means of connecting to the service. There are VDSL, Fiber and IP-DSL depending on where your home or office is located. Closer in and you are
more likely to get service via VDSL, in Apartments or other similar locations you may get service via Fiber, and if you are outside those areas but
within ADSL ranges you are more likely to be served by ADSL2+.
•
Authentication onto the network is different, there is no PPPoE authentication on the AT&T U-verse network.
•
Due to the architecture of the AT&T U-verse platform, Bridge mode is not supported on the network nor on the RG. There will be separate subsections dealing with how best to configure the RG for your particular need instead.
•
Ping and Trace – by default AT&T U-verse RG’s are set to not respond to ICMP requests such as Ping and Trace. This is configurable through the user
interface. Also as the network utilizes MPLS your trace routes will often have lines which time out. This is not an indicator of trouble it is just that
that particular hop or node is not set to reply to ICMP requests. This is very much a common policy today as answering ICMP requests adds to CPU
utilization and can impact network performance when attacks are made via mass ICMP request attempts commonly referred to as Denial of Service
attacks.
•
Use of 10.x.x.x IP addresses – the DHCP server in the RG is configured not to allow 10.x.x.x IP scope to be set as the DHCP IP addresses. You may
continue to use 10.x.x.x addresses on the LAN side of a 3rd party router but the RG can not be configured to hand out 10.x.x.x. IP addresses.
•
Static IP delivery –
•
with your DSL service the DSL modem was often set to bridge mode, one IP address was used at the Access device on our side as the
Gateway IP address and minus the Network and Broadcast IP addresses the rest were for users to configure on their equipment with the
customer device being the next logical hop out from the Access device. (For those with a single Static IP there is no equivalent in U-verse
today.) Also note that you will not be able to keep any existing Static IP addresses. They are a part of a larger block routed for DSL service.
•
With AT&T U-verse the RG is now our access device for this scenario. It has its own IP for its WAN which is a sticky dynamically assigned IP.
A Virtual port is then created on the LAN side for the Public / Static IP block and like the DSL Access device uses one IP from the block as the
Gateway. The remaining are handed to the customer device.
•
A common misconception is that using DMZplus / IP Passthrough (depending on device) will completely remove the RG as the firewall and
the Gateway. Neither of them are the case in general. Those modes pass the sticky DHCP assigned IP of the RG WAN connection, which is
separate from the Static IP block , to the assigned device. Also there is always a portion of the RG’s firewall functionality that remains in
place by design for our U-verse services. This will be discussed in later sections of the document.
These are some of the differences that are most likely to impact you in your migration.
Page 2
DMZplus / IP Passthrough
DMZ mode on many home routers and broadband devices bypasses the firewall with an effective any-to-any
filter. Meaning any IP or port can go to any IP or port. The intent being to let the assigned device placed into
the DMZ handle its own security.
DMZ mode is known as DMZplus on the Pace RG’s 3800, 3801, iNID and newer devices.
DMZ mode is known as IP Passthrough on the Motorola RG’s NVG510 and newer. (note – presently IP
Passthrough hands off a /32 subnet which does not include the gateway IP and so you should manually /
statically assign the IP and subnet mask after it hands it off. A fix for this is scheduled for this.)
For AT&T U-verse this is still the general intent but due to some requirements for the U-verse platform even
when in these modes there are some situations where the behavior will not be what you expect.
This mode will work well for a user placing a PC in DMZ mode. It will work in many cases for a customer
placing their own router in DMZ mode and are not using Static IP’s offered by AT&T’s Static IP Service.
It is recommended however for consistency or if you are using Static IP’s or VPN connections that you not use
DMZ mode and instead create firewall rules / pinholes to allow the ports you need for a device. To some
extent this can be an any to any rule. More discussion on doing this is included later in the document.
Page 3
VPN and AT&T U-verse
When using VPN across the AT&T U-verse platform it is often necessary to
lower the MTU (Maximum Transmitable Unit) setting of the VPN client or if using a
concentrator then the egress port to the AT&T U-verse RG to 1472. Common
symptoms of MTU needing to be lowered would be VPN connections not
being stable or having very poor performance for applications and browsing
that traverses the VPN.
Often lowering the MTU on your end alone will correct this, sometimes it
may additionally require adjustment on the far end as well.
Also a note on the Motorola NVG510 – VPN connections using PPPTP or
L2TP will require setting up the GRE ALG option (or PPTP etc) in the
NAT/Gaming section.
Page 4
Now How Do We Configure the RG for these things?
The rest of the document is divided into sections covering the Pace devices
and separate sections for the Motorola devices.
As this will be delivered in a PDF document there will be bookmarks for the
sections so you may skip to those applicable to you.
Page 5
Configuring U-verse Pace devices
3600 / 3800 /3801/5031/5168 and iNID
for use with 3rd party Firewall / Router devices.
Pace 3600, 3800, 3801, 5031, 5168 and iNID devices.
This section walks through configuring the PACE RG to work with 3rd Party
routers or firewall devices. For those migrating from a DSL or other service
which would allow them to put the modem into a “Bridge” mode.
Page 6
U-verse Platform Gateways (RG’s) –
Do Not Have a Bridge Mode.
As mentioned earlier in the document the Firewall is never completely out of the
picture. Configurations can be made to allow much of the behavior typically
needed when using a bridge mode but there may be some limitations for those
with more advanced needs.
Those limitations can mostly be overcome once the user understands this and is
willing / able to adapt how things on the LAN are configured and update. What
can be done is based on the need such as Basic service using DMZplus or Static IP
service.
For those needing 3rd party routers and or firewall devices between the RG and
their network it is better for the U-verse Platform RG’s to leave the Firewall
enabled and to create pinholes for the traffic that is expected / required to be
used. This especially applies to any traffic that could or would be initiated from
the WAN side such as a remote location. It is also recommended when applicable
to use DHCP IP assignment to the 3rd party Router or Firewall for its connection.
Page 7
Configuring the 3600, 3800, 3801 or iNID Firewall
Open the RG’s portal page by entering the LAN side IP of the RG (192.168.1.254 is the default private IP.) If
using the Static IP block go to the Gateway IP for the block (typically the next to last IP in the block)
You should see a page like this at the top:
or
Then go to the Settings tab
Page 8
Next go to the Firewall option
Select the Applications, Pinholes and DMZ option
Page 9
Next we will create a new user-defined application (read as rule or template) which we will then apply to
the 3rd party Firewall or Router device. Click on the Add a new user-defined application option under the list
of existing applications.
Page 10
1. Give it an application Name
Next we will enter the ports we need available for this rule or application.
2. Select TCP or UDP
3. Enter the port range – I typically repeat
the port if single. NOTE – Although you
could specify 0 to 65000 or the highest
port number to achieve an effective
ANY ANY – the Pace device will not
allow you to save it in that manner.
You will need to leave some for its own
use. So you will need to break it up
into 2 or more and leave some available
for the RG’s own use.
4. Protocol timeout can be left for default.
5. Map to Host Port can be left for default
6. Application type is to let the RG know if
the port is for a particular kind of
service that it needs to handle
separately from its own services. Some
of those listed are for DNS, SIP, FTP
and few others.
7. Click Add to List
8. The area under Definition List will list
the sub rules you have Added for this
App.
9. Repeat for each port / port range
needed.
So you would have 1 rule for each port
you need in particular for traffic that is
or could be initiated remotely and for
each port as separate rule for TCP and
UDP as needed.
Once you have added all of them click
the back button. This will save the
application definition with all entries in
this case to the name you gave it.
Page 11
Next we will apply the custom rule.
1. First you will need to Select the
device you are applying the rule to.
(from the list near the top.) Once you
have selected it it will show You have
chosen it. (NOTE – it is better to
assign rules to Devices rather than to
IP addresses. This way if for any
reason the IP address of the device
changes the rule will still work. So for
example if for some reason the Public
IP block stops working the private IP
could be used and no changes to the
rule would be required.)
2. Select Allow Individual applications
3. Scroll through the list of Applications
in the Application List box and select
the rule you just created.
4. Click the Add button to the right of
the list between the columns.
5. It will now appear in the Hosted
Applications list.
6. Click the Save button further down
the page on the right.
7. This has now applied the rule.
Page 12
To verify it is applied at the top of the page where the Firewall tab is select the Status option.
Page 13
You should now see something like the following. Do not worry about the Application Type not reflecting
the FTP portion – it is because this has multiple definitions within the one Application rule.
Page 14
Firewall – Advanced Settings – Allowing Ping
By default the U-verse RG does not reply to Ping or
Trace and does not allow those to be passed thru the
firewall from the WAN side.
To enable Ping and Trace two settings must be
changed. This can be done on the Settings / Firewall /
Advanced Configuration page
Stealth Mode – Remove the check mark. This settings
by default means the RG does not itself respond to
ICMP queries.
Block Ping – Remove the check mark. This setting is
what will allow Ping and Trace commands through the
firewall from the LAN side.
NOTE – at this time the consistency of the replies even
with these settings will vary.
A note about ping and trace – the standard form of IP Ping
and Trace use ICMP requests.
ICMP requests are quite often not answered or answered with
a very low priority. Actual data traversing the same hop has a
higher priority and does not experience the same delay. So
for example in a trace today you may see time outs but the
trace completes. The time outs do not indicate a problem but
instead indicate only that those hops are configured not to
reply to ICMP requests. Also if the destination device is set to
not reply then a ping or trace can time out and still not be an
accurate indicator of if there is a problem.
This is mentioned to keep in mind not to use this as your only
or even primary trouble indicator.
Page 15
Configuring Static IP
This Section will walk you through configuring the RG for use of a Static IP
block. As mentioned earlier but repeated here for convieniance is an overview
in differences between ADSL service handling of Static IP service and AT&T Uverse
•
Static IP delivery –
Page 16
•
with your DSL service the DSL modem was often set to bridge mode, one IP address was used at the Access
device on our side as the Gateway IP address and minus the Network and Broadcast IP addresses the rest
were for users to configure on their equipment with the customer device being the next logical hop out
from the Access device.
•
With AT&T U-verse the RG is now our access device for this scenario. It has its own IP for its WAN which is
a sticky dynamically assigned IP. A Virtual port is then created on the LAN side for the Public / Static IP
block and like the DSL Access device uses one IP from the block as the Gateway. The remaining are handed
to the customer device.
•
A reason this is different is that the Static IP block is routed to the WAN IP (dynamically assigned) of the RG
and mapped to the MAC address of the RG for anti-spoofing purposes.
•
The common misconception is that using DMZplus / IP Passthrough (depending on device) will completely
remove the RG as the firewall and the Gateway. Neither of them are the case in general. Those modes
pass the sticky DHCP assigned IP of the RG WAN connection, which is separate from the Static IP block , to
the assigned device. Also there is always a portion of the RG’s firewall functionality that remains in place by
design for our U-verse services. This will be discussed in later sections of the document.
Enable Public Routed Sub-interface
This section would have been completed by the U-verse installer and is
provided here for reference to verify it is configured as suggested. Also
in case of a factory reset where it is required to be reconfigured.
1. Determine the Public IP block information to configure in the
Residential Gateway. (example x.x.x.x /29)
The RG will use two sets of Public IP addresses, one IP for use between the router and the broadband network (WAN
side)and a second independent set of Public Static IP addresses solely for use on the LAN side. The WAN side IP is a
Dynamically assigned IP address that is “sticky” It should change only under certain conditions. Some of those
conditions are
•
The RG is replaced by another RG
•
The VDSL port is swapped at the DSLAM
•
The RG is offline for an extended time which could then fail to renegotiate its IP lease.
The Public / Static IP block will be dynamically mapped and routed to the WAN IP and a single IP out of the
block will be assigned to a virtual port on the LAN side of the RG. That IP will be the gateway for the rest of the
devices using the Static IP block behind the RG. Typically we use the next to last IP in the block for this Gateway
IP.
Page 17
Log into the RG GUI page by putting in the gateway IP (192.168.1.254 is
default address. )
You should see the opening screen of the portal with something like this.
Then click on the Settings tab which will bring you to a page like this:
Page 18
Now click on the Broadband
Click on the Link Configuration option.
Page 19
Go to the Supplementary Network section near the bottom of the page.
or
The Add Additional Network box for Enable should be checked.
The Router Address will be one of the available IPs from the Static / Public block issued. Typically this would
be the next to the last IP in the block but the 2nd one is another common one. The Subnet Mask should be set
to 255.255.255.x where x depends on the amount of IP addresses you have. Start with 255 and subtract the
number of IP addresses in your block and that will be the subnet value for x. For example 8 IPs would be
248
The Auto Firewall Open box should be checked. This in particular applies to connection requests generated
by devices on the LAN and using one of the Static IP addresses. Rules should still be made for connection
requests or traffic originating on the WAN / Internet side of things. We will cover how that works later.
Some devices and firmware also support Cascaded Router.
This option allows the RG to route the entire Public IP block over to a particular device or IP address. Think of it as a next hop
situation. In this mode the RG does not reserve one of the Public IP addresses for a virtual interface, instead it is configured to
route any IP addresses in the configured block over to the specific device or private IP address. The destination router then
would use, hand out via DHCP and route the Public IP block.
To enable Cascaded Router place a check in the Enable box next to it. Then add in the Public IP block in the Network
Address and the Subnet Mask. Then choose the radio button for either the device and select the device in the drop down
menu or select and enter the IP private IP address of the device you will route to.
Page 20
Next go to the LAN tab
Click on the DHCP
Page 21
This section is to verify what DHCP scope or range you wish the RG to use by default (you can assign
manually in another section but this would be which it uses by default. You can select Private Network or
Public Network if the Public Interface and block information has been configured. Click Save if you have
changed anything. NOTE - if you used Cascaded Router configuration - this step does not apply.
Page 22
Configuring U-verse Arris NVG510 or NVG589 for use
with 3rd party Firewall / Router devices.
This section walks through configuring the Arris NVG510 or NVG589 RG to work
with 3rd Party routers or firewall devices. For those migrating from a DSL or
other service which would allow them to put the modem into a “Bridge”
mode.
Page 23
U-verse Platform Gateways (RG’s) –
Do Not Have a Bridge Mode.
As mentioned earlier in the document the Firewall is never completely out of the picture.
Configurations can be made to allow much of the behavior typically needed when using a
bridge mode but there may be some limitations for those with more advanced needs.
Those limitations can mostly be overcome once the user understands this and is willing /
able to adapt how things on the LAN are configured and update. What can be done is
based on the need such as Basic service using IPPassthrough or Static IP service.
For those needing 3rd party routers and or firewall devices between the RG and their
network it is better for the U-verse Platform RG’s to leave the Firewall enabled and to
create pinholes for the traffic that is expected / required to be used. This especially applies
to any traffic that could or would be initiated from the WAN side such as a remote location.
It is also recommended when applicable to use DHCP IP assignment to the 3rd party Router
or Firewall for its connection.
The Arris NVG510 or NVG589 offers a little more choices in the Firewall configuration, this section
will include screenshots of these pages and a brief description of their use in general along
with a general walk thru of configuring the NAT / Gaming section which is where the
pinhole recommendation would be configured.
Page 24
Configuring the Arris NVG510 or NVG589 Firewall
Open the RG’s portal page by entering the LAN side IP of the RG (192.168.1.254 is the default private IP.) If
using the Static IP block go to the Gateway IP for the block (typically the next to last IP in the block)
You should see a page like this:
Page 25
Click on the Firewall tab. This will bring you to the status page.
Page 26
Click on the Packet Filter tab.
This tab is for those situations
where Packet Filtering is
needed. For instance if you
have a range of IP addresses to
allow traffic to or from rather
than a singe IP on the LAN side
or from the LAN to an IP or IP
range to allow traffic to.
Where the NAT/Gaming will be
to allow an identified port to a
single device or IP.
Page 27
Click on the NAT/Gaming tab.
This tab is for those situations
where a NAT/Gaming pinhole is
needed.
An example is for passing traffic
through to a Firewall / VPN /
Router device as a single
handoff from the Arris RG or modem.
In the Application Hosting
Entry section there are a
number of commonly defined
applications you may select
from. Be sure to use the
Service Details button to verify
the port ranges defined match
your particular need for the
app.
If you need to or prefer to
define you own rule for each
port or application you may use
the Custom Services section.
We will walk thru Custom
Services creation further on.
Page 28
The Service Details button.
This is an example of the Service
Details page.
Here you will see the Service
Name / the custom name you
gave a rule.
It lists Protocol (TCP, UDP, or both)
It also lists the Global Port Range
you want to have opened.
So for the pre-defined rules they
use the common ports used for
those services. But your own
needs may call for different ones.
So just be sure to see what is
being used.
NOTE – there are pre-defined
services for IPSec – IKE as well as
for PPTP which can be helpful for
VPN usage.
Page 29
The Custom Services button.
This is an example of the Custom
Services page.
Here you will see the Service List
which will display the services you
define once you add them.
The Service Entry area is where
you define you custom rule.
Service Name – give it a custom
name – typically the name of the
app or service that uses this port.
Global Port Range – give a
beginning and ending port range.
If a single port then place in both.
Base Host Port the same port as
above typically.
Protocol – select TCP, UDP or Both
Click Add
This will then show the definition
in the Service List Box.
Page 30
Click on Return to NAT/Gaming to
continue.
Returned to the NAT/Gaming tab.
Now that you have created a
custom services rule.
Click on the drop down box for
Service and find the new
custom service definition you
created.
Then click on the drop down
box next to Needed by Device
and select the device you wish
to apply it to such as your PC,
Router, Firewall or VPN
appliance.
Click Add
This should now show that
custom service above in the
Hosted Applications section.
Remember you will have to
apply a rule custom or
otherwise for each port /
service you will need open to
that device.
Page 31
Firewall – Allowing Ping and Trace
By default the U-verse RG does not reply to Ping or
Trace and does not allow those to be passed thru the
firewall from the WAN side.
To enable Ping and Trace on the NVG510 we must
use the Packet Filter tab in the Firewall.
We would need to change the Enable Filter to On
We need to then drop down to the Filter Rule Entry
section and select Pass
Then enter the Source IP or IP range from which we
wish to accept Pings / Traces from – typically the home
office or a managing location.
Then enter the Destination IP Address Range –
again a single IP or and IP range to allow Pings to at
this location. Such as the IP of the RG, or a PC or
Router / Firewall behind the RG or for Static IP
addresses behind the RG.
Then select the Protocol – ICMP for Ping and Trace.
Source Port and Destination Port can be left blank as
this is for TCP / UDP traffic not ICMP.
ICMP Type can also be matched
Page 32
A note about ping and trace –ICMP requests are quite often
not answered or answered with a very low priority. Actual
data traversing the same hop has a higher priority and does
not experience the same delay. So for example in a trace
today you may see time outs but the trace completes. The
time outs do not indicate a problem but instead indicate only
that those hops are configured not to reply to ICMP requests.
Also if the destination device is set to not reply then a ping or
trace can time out and still not be an accurate indicator of if
there is a problem. So keep this in mind.
Configuring Static IP
This Section will walk you through configuring the RG for use of a Static IP
block. As mentioned earlier but repeated here for convenience is an overview
in differences between ADSL service handling of Static IP service and AT&T Uverse
•
Static IP delivery –
Page 33
•
with your DSL service the DSL modem was often set to bridge mode, one IP address was used at the Access
device on our side as the Gateway IP address and minus the Network and Broadcast IP addresses the rest
were for users to configure on their equipment with the customer device being the next logical hop out
from the Access device.
•
With AT&T U-verse the RG is now our access device for this scenario. It has its own IP for its WAN which is
a sticky dynamically assigned IP. A Virtual port is then created on the LAN side for the Public / Static IP
block and like the DSL Access device uses one IP from the block as the Gateway. The remaining are handed
to the customer device.
•
A reason this is different is that the Static IP block is routed to the WAN IP (dynamically assigned) of the RG
and mapped to the MAC address of the RG for anti-spoofing purposes.
•
A common misconception is that using DMZplus / IP Passthrough (depending on device) will completely
remove the RG as the firewall and the Gateway. Neither of them are the case in general. Those modes
pass the sticky DHCP assigned IP of the RG WAN connection, which is separate from the Static IP block , to
the assigned device. Also there is always a portion of the RG’s firewall functionality that remains in place by
design for our U-verse services. This will be discussed in later sections of the document.
Enable Public Routed Sub-interface
This section would have been completed by the U-verse installer and is
provided here for reference to verify it is configured as suggested. Also
in case of a factory reset where it is required to be reconfigured.
1. Determine the Public IP block information to configure in the
Residential Gateway. (example x.x.x.x /29)
The RG will use two sets of Public IP addresses, one IP for use between the router and the broadband network (WAN
side)and a second independent set of Public Static IP addresses solely for use on the LAN side. The WAN side IP is a
Dynamically assigned IP address that is “sticky” It should change only under certain conditions. Some of those
conditions are
•
The RG is swapped
•
The VDSL port is swapped at the DSLAM
•
The RG is offline for an extended time which could then fail to renegotiate its IP lease.
The Public / Static IP block will be dynamically mapped and routed to the WAN IP and a single IP out of the block will be
assigned to a virtual port on the LAN side of the RG. That IP will be the gateway for the rest of the devices using the
Static IP block behind the RG. Typically we use the next to last IP in the block for this Gateway IP.
NOTE – if using Cascaded Router config (discussed later) instead of keeping an IP out of the Static IP block to act as a gateway
the RG will hand the entire block off to a 3rd party router connected to the Arris RG or modem via private IP, for use on the LAN
side of the 3rd party router.
Page 34
Log into the RG GUI page by putting in the gateway IP (192.168.1.254 is
default address and a URL for this is …..)
You should see the opening screen of the portal with something like this.
Page 35
Click on the Home Network tab which take you to the Status page
Page 36
Click on the Subnets & DHCP sub-tab which take you to this page
Here you will see the Private LAN subnet
configured.
Below that the Public Subnet section. Here is
where we will configure your Static IP block
for use.
Turn the Public Subnet Enable to On
Pubic IPv4 Address is the IP the RG will use as
the Gateway IP for the rest of your block
typically this is the next to last IP in your
block.
Public Subnet Mask is in the format of
255.255.255.x with x depending on the
number of IP addresses in your block so for 8
Ips this would be 255 – 7 (one less than the
number of IP addresses)= 248 so
255.255.255.248
DHCPv4 Start Address is the start address of
the usable IP addresses to be assigned.
DHCPv4 End Address would be the last
assignable IP which would in our example be
one less than the Gateway IP address.
Primary DHCP Pool is to determine which IP
pool is default Private pool or Public Pool.
Page 37
Save
Using Cascaded Router configuration
Cascaded Router mode should only be used
by Advanced users who understand the
implications.
Cascaded Router will as stated earlier, hand
the entire Static IP block to a 3rd party router
for it to handle the routing and IP assignments
of the block.
That router will be connected to the RG using
a private IP, which means that the Static IP
block will be NAT’ed from the 3rd party router
out to the RG or modem and the Internet.
Cascaded Router and Public Subnet
configuration can not both be enabled.
-------------------------------------Cascaded Router Enable – set to On
Cascaded Router Address – the private IP of
the 3rd Party router that you will hand off and
configure the Static IP block on
Network Address is the starting IP of the
Static IP block
Subnet Mask is the subnet mask that matches
the Static IP block (255.255.255.248 if 8 IPs)
Page 38
Save
Configuring for IP Passthrough mode
Click on the Firewall tab.
Page 39
Click on the IP Passthrough sub-tab
IP Passthough will share the WAN IP of the RG
or modem to the specific device. It will not be
one of the Static IP’s assigned if you have
those. It will not completely bypass the
firewall but for most uses it will and in many
cases you can add pinhole rules for any that
may not work as expected while in this mode.
Allocation Mode – set to Passthrough
Default Server Internal Address – not used
for Passthrough mode
Passthrough Mode – by default this is set to
DHCPS-dynamic.
Passthrough Fixed MAC Address – the MAC
Address of the device to be used in
Passthrough mode
Passthrough DHCP Lease – if you wish to
modify the lease time.
Save
IP Passthrough may be enabled along with Cascade
Router.
Page 40
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising