Escolar Documentos
Profissional Documentos
Cultura Documentos
Date: Version:
Abstract:
This application note provides technical information on how the Thomson Gateway DSL routers can be integrated in various scenarios where more than 1 public IP address is offered to the customer. A multitude of concepts exists, combining different ways of how the IP ranges are offered to the customer (dynamically or statically) and how the IP addresses will be integrated at the customers premises (routed by the Thomson Gateway to a local public subnet or terminated on the Thomson Gateway and redirected to specific hosts by Hyper-NAT. Thomson Gateway DSL Gateways and Routers R6.2.x Thomson continuously develops new solutions, but is also committed to improving its existing products. For more information on Thomson's latest technological innovations, documents and software releases, visit us at http://www.thomson-broadband.com
Applicability: Updates:
Contents
1 2
2.1 2.2
3
3.1 3.2
4
4.1 4.2
5
5.1 5.2
6
6.1 6.2
Multi-NAT ................................................................................... 27
Scenario Overview ........................................................................................ 27 Practical Realisation ..................................................................................... 29
7
7.1 7.2
8
8.1 8.2
9
9.1
E-DOC-CTC-20051017-0157 v2.0
Contents
9.2
E-DOC-CTC-20051017-0157 v2.0
ii
Contents
iii
E-DOC-CTC-20051017-0157 v2.0
Chapter 1
Introduction
Document Overview
A brief overview of the sections available in this Application Note: 2 Static Subnet with Numbered WAN Link on page 6 This is the most basic model that exists. The complete range of public IP addresses is located in a local subnet, and this subnet is connected to the Internet Service Provider (ISP) through the Thomson Gateway by means of a connection which has its own IP definition. 3 Static Subnet with Unnumbered WAN Link on page 11 When point to point links are used, it can be interesting to put these links in unnumbered mode to avoid the waste of IP addresses, or to avoid the configuration of private, dummy, routing networks. However, this has a few side-effects, such as source IP selection of Thomson Gateway originated traffic. 4 Static Subnet in Full Unnumbered mode on page 16 When remote access to the Thomson Gateway is not required, the fully unnumbered mode is a very interesting solution. In this mode, one of the available public IP addresses that would normally be used on the Thomson Gateway is now available for use by a local host. 5 Subnet with IPCP Subnet Mask Option on page 21 Another option is to implement a (semi-)dynamic public subnet model. On top of the extra functionality offered by PPP by means of authentication and accounting, an extension is also available to dynamically offer a whole subnet to the PPP client. An example is provided on how to enable this feature on a Thomson Gateway, and how the distribution of the subnet towards the other devices has to be handled. 6 Multi-NAT on page 27 With Multi-NAT, pure NAT is applied, meaning that there is a 1-1 relation between a private and public IP address. The Multi in Multi-NAT means that this 1-1 relation does not have to be defined in advance, hence, there can be more private hosts than public IP addresses. The relation will be established when the first packet is sent. From then on, a specific public address is reserved for the related private host. 7 Transparent NAT on page 31 This type of NAT is mostly used in combination with other flavours, as it is quite a special one. The strange thing is that no NAT is performed, but the packets are transparently forwarded from the public into the private segment of the network, where a host is configured with that particular public IP address. This feature is useful when an interface is in NAT mode, but part of the IP addresses on it should not be translated. In that case, for these IP addresses, a transparent NAT entry should be defined. 8 X+n NAT on page 36 This feature can be useful when a range of IP addresses has to be dynamically assigned to a certain customer, but the protocol used for the dynamic distribution (typically PPP-IPCP) does not support the offering of more than 1 IP address. Some solutions define that if IP address X is offered, the next n IP addresses are also available for use. To handle these kind of forced IP range definitions, the use of N+x NAT templates is needed.
E-DOC-CTC-20051017-0157 v2.0
Chapter 1
9 Public IP address Distribution by Hyper-NAT on page 40 The Thomson Gateway NAT implementation, Hyper-NAT, offers many types of NAT configuration. One of the powerful capabilities of Hyper-NAT is that all these different NAT flavours can be used in a mixed mode. This can be very interesting in case a user has a range of public IP addresses available, and wants to use each one of them to fulfil a specific need.
E-DOC-CTC-20051017-0157 v2.0
Chapter 2
Introduction
This chapter describes the most basic model that exists. In this model, the complete range of public IP addresses is located in a local subnet, and this subnet is connected to the ISP through the Thomson Gateway by means of a connection which has its own IP definition
2.1
Concept
Scenario Overview
In this scenario the ISP provides the following configuration parameters to the customer: The ATM connection parameters (VPI/VCI, encapsulation type, connection type), A range of public IP addresses (the MyIP addresses), An additional IP address to be used for interconnecting with the ISP (the Route-IP), The IP address of the gateway, Probably some extra parameters as DNS and other servers IP addresses (or host names).
NOC
Web Route IP MyIP1 MyIP4
Internet
1 PVC
My Public Subnet
MyIP2 MyIP3 Mail
BAS
GW
Proxy
Figure 1 Concept drawing of subnet with routing IP The route-IP address can be a public IP address, but often the ISP will prefer to use private IP ranges for this intermediary routing network. The advantage of using private ranges is that: If the Network Operations Centre (NOC) of the ISP is also located in this private subnet, only the ISP is able to access the Thomson Gateway itself from the WAN-side. This means that if specific services (think of remote access, SLA monitoring and so on) are enabled on the WAN side they will not be accessible by every host on the Internet. No valuable public IP addresses are wasted simply to establish Internet connectivity.
E-DOC-CTC-20051017-0157 v2.0
Chapter 2
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
202.202.203.17
172.16.5.57
202.202.203.22
Internet
PVC: 8/35
202.202.203.19
Figure 2 Scenario example of subnet with routing IP The following sections will describe all the configuration steps needed:
To...
Create the Uplink Interface Define the Local Public Subnet Define the Routing towards the Internet Enable DNS Forwarding Set the Correct Firewall Level
See page...
8 9 9 9 10
E-DOC-CTC-20051017-0157 v2.0
Chapter 2
2.2
Practical Realisation
Create an IP interface. Execute the following CLI commands to create IP interface ip_MyIPoA and to assign an IP address to it:
:ip ifadd intf=ip_MyIPoA dest=atm_MyIPoA :ip ipadd intf=ip_MyIPoA addr=172.16.5.57 pointopoint=202.202.202.1
In this last command you can see how the IP addresses on the WAN side of the Thomson Gateway are assigned as defined in Figure 2. The addr parameter sets the local address (the route-ip as we called it conceptually); the address of the Broadband Access Server (BAS) is defined through the pointopoint parameter. 3 Enable the IP interface. Execute the following CLI command to enable IP interface ip_MyIPoA:
:ip ifattach intf=ip_MyIPoA
Check the initial connectivity. Execute the following CLI command to check whether basic connectivity is available between the Thomson Gateway and the gateway of the ISP:
=>:ip debug ping addr=202.202.202.19 bytes from 202.202.202.1: icmp_id=27, icmp_seq=0
When the CLI command does not generate any feedback (9 bytes from...), this means that the test is failing. Be aware that this test will only succeed if the BAS is not configured to discard ICMP echo requests.
E-DOC-CTC-20051017-0157 v2.0
Chapter 2
With the addroute=enabled parameter, a route is automatically injected in the routing table. This route indicates that subnet 202.202.203.16/29 is directly connected via interface lan1, being the local Ethernet interface.
All hosts will need to configure the IP address of the Thomson Gateway as their primary DNS server (that would be 202.202.203.22 for this scenario). The IP address of the DNS server that is used in the CLI command (202.204.54.20) will be provided by your ISP.
E-DOC-CTC-20051017-0157 v2.0
Chapter 2
If your current level is not as desired, execute the following CLI command to correct this:
:firewall level set name=Disabled
It is very important to know that firewall level Disabled does not mean the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually level Disabled means that all traffic coming in on one interface and going out on another, is allowed. But still the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and others stay enabled as well - as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, please refer to the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
E-DOC-CTC-20051017-0157 v2.0
10
Chapter 3
Introduction
When point-to-point links are used it can be interesting to put these links in unnumbered mode to avoid the waste of valuable IP addresses. However, when there is no IP interface on a link, some side-effects have to be looked at. Possible hiccups are source IP selection of Thomson Gateway originated traffic towards the WAN and defining interface routes instead of gateway routes.
3.1
Concept
Scenario Overview
In this scenario the ISP provides the following configuration parameters: The ATM connection parameters (VPI/VCI, encapsulation type, connection type IPoA), A range of public IP addresses (the MyIP addresses), Probably some extra parameters as DNS and other servers IP addresses (or host names), Optionally, the IP address of the gateway. The WAN link will be configured in unnumbered mode. This implies that the IP interface itself will exist, but will not have an IP address assigned to it. When forwarding traffic this is no issue at all, as a router does not change any packets but just sends them out on a certain interface. In case the Thomson Gateway wants to generate traffic itself, however, it will have to choose a source IP address to use in the IP packet that it is going to send. How this selection is made, and how we can make sure a correct address is used will be described later in this chapter.
No IP
Web
MyIP1 MyIP4
Internet
1 PVC
My Public Subnet
MyIP2 MyIP3 Mail
BAS
GW
Proxy
Figure 3 Concept drawing of unnumbered WAN interface In addition, the lack of having the gateway IP address is not really an issue. The advantage of IPoA is that it is a point-to-point connection model. As in any point-to-point model on the Thomson Gateway, it is possible to forward traffic to an interface rather than to the IP address of the next hop. The main reason is that these two mean the same in a point-to-point model, because there is only one host on the other side on each link. So if you forward a packet on a link, or to the IP address of the remote peer, it always ends up at the same destination.
11
E-DOC-CTC-20051017-0157 v2.0
Chapter 3
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
202.202.203.17
No IP
202.202.203.22
Internet
PVC: 8/35
202.202.203.19
To...
Create the Uplink Interface Define the Local Public Subnet Define the Routing towards the Internet Set the Default IP Address Enable DNS Forwarding Set the Correct Firewall Level
See page...
13 13 14 14 15 15
E-DOC-CTC-20051017-0157 v2.0
12
Chapter 3
3.2
Practical Realisation
Create an IP interface. Execute the following CLI commands to create IP interface ip_MyIPoA:
:ip ifadd intf=ip_MyIPoA dest=atm_MyIPoA
No IP address is assigned to this IP interface. 3 Enable the IP interface. Execute the following CLI command to enable IP interface ip_MyIPoA:
:ip ifattach intf=ip_MyIPoA
By the addroute=enabled parameter, automatically a route is injected in the routing table indicating that the subnet 202.202.203.16/29 is directly connected to interface lan1, being the local Ethernet interface.
13
E-DOC-CTC-20051017-0157 v2.0
Chapter 3
Execute the following CLI command to verify the default IP addresses of the Thomson Gateway IP interfaces:
=>:ip iplist Interface 5 guest1 4 dmz1 3 lan1 3 lan1 0 loop =>
The IP-address preceded by an asterisk (*) is the primary address of an interface. Execute the following CLI command to verify the default IP interface of the Thomson Gateway:
=>:ip iflist expand=enabled Interface Group MTU RX TX TX-Drop Status HW-address ... 2 lan1 lan 1500 3729936 19533329 0 [UP] 00:0e:50:34:00:f2 BRHW-address : ff:ff:ff:ff:ff:ff RX unicastpkts: 37401 brcastpkts : 5716 TX unicastpkts: 40058 brcastpkts : 2855 droppkts:0 Oper state : UP Admin State: UP Flags : PRIMARY ARP BROADCAST BOUND ARPTABLE MULTICAST NAT TRANSNAT STATIC ... =>
All IP interfaces that are configured on the Thomson Gateway will be displayed, but only one will have the primary flag set.
E-DOC-CTC-20051017-0157 v2.0
14
Chapter 3
All hosts will need to configure the IP address of the Thomson Gateway as their primary DNS server (for this scenario, that would be 202.202.203.22 ). The IP address of the DNS server used in the CLI command (202.204.54.20) will be provided by your ISP.
If the current level is not as desired, execute the following CLI command to correct this:
:firewall level set name=Disabled
It is very important to know that firewall level Disabled does not mean the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually level Disabled means that all traffic coming in on one interface and going out on another, is allowed. Nevertheless, the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and others stay enabled as well - as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
15
E-DOC-CTC-20051017-0157 v2.0
Chapter 4
Introduction
When remote access to the Thomson Gateway is not required, the fully unnumbered mode is a very interesting solution. In this mode, one of the available public IP addresses that would normally be used on the Thomson Gateway is now available for use by a local host. When the ISP offers very small ranges of IP addresses, for example four IP address subnets (where of the 4 IP addresses one is the netID, one is the broadcast address, and a third one is used on the Thomson Gateway), only one address can actually be used. By configuring the Thomson Gateway in fully unnumbered mode, a second IP address becomes available for customer use.
4.1
Concept
Scenario Overview
In this scenario the ISP provides the following configuration parameters: The ATM connection parameters (VPI/VCI, encapsulation type, connection type PPP), A range of public IP addresses (the MyIP addresses), The user name and password for the PPP connection, Probably some extra parameters as DNS and other servers IP addresses (or host names). The complete device will be in unnumbered mode. For the WAN side this means that the point to point link will be in unnumbered mode. For the LAN side this means that there will be no public IP address configured here either, but the private range IP configuration will preferably stay available to allow local administration of the Thomson Gateway.
Web
MyIP1
Internet
1 PVC
My Public Subnet
MyIP3 MyIP2 Mail
BAS
GW
Proxy
Figure 5 Concept drawing of full unnumbered mode The local hosts will have to be manually configured with the public IP addresses as provided by the ISP. They will have the IP address of the BAS configured as default gateway. Locally all hosts are on an Ethernet network, so if they want to send traffic, they will send out an ARP (Address Resolution Protocol) message to resolve the Ethernet-address (MAC address) to which they have to direct their packets. As ARP messages are Ethernet packets, they cannot pass a router (in this case the Thomson Gateway), meaning the BAS itself will never receive any ARP request. The solution is to let the Thomson Gateway respond to the ARP requests for the Gateway IP. This is called a proxy-ARP entry.
E-DOC-CTC-20051017-0157 v2.0
16
Chapter 4
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
Internet
PVC: 8/35
Figure 6 Scenario example of full unnumbered mode The special part of this configuration is the default gateways IP address is not located in the subnet that is available for the customer (202.202.203.16/29). Therefore all local clients must be configured as if they were part of a larger subnet (202.202.203.1/24) to enable connectivity with their default gateway. The following sections will describe all configuration steps needed:
To...
Create the Uplink Interface Define the Local Public Subnet Proxy ARP for the Gateway Check Connectivity Set the Correct Firewall Level
See page...
18 19 19 19 20
17
E-DOC-CTC-20051017-0157 v2.0
Chapter 4
4.2
Practical Realisation
For IPoA, the corresponding commands are the same, but the ulp parameter is ulp=ip 2 Create a PPP interface. Execute the following CLI commands to create PPP interface ppp_MyPPP:
:ppp ifadd intf=ppp_MyPPP :ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword unnumbe red=enabled
The values MyUsername and MyPassword should be replaced by the actual PPP connection credentials that are offered by your ISP. For IPoA the corresponding commands are :ip ifadd and ip ifattach. The unnumbered=enabled parameter of the PPP interface is reflected in IPoA by not adding an IP address to the IP interface you are creating. 3 Define a route to the internet. Execute the following CLI command to inject a default route into the routing table from the moment the PPP link is connected and the IP negotiation was successful:
:ppp rtadd intf=ppp_MyPPP dst=0.0.0.0/0
For IPoA the corresponding command would be :ip rtadd 4 Connect the PPP interface. Execute the following CLI commands to connect the PPP interface:
:ppp ifattach intf=ppp_MyPPP
E-DOC-CTC-20051017-0157 v2.0
18
Chapter 4
The value $_MACADDR will automatically resolve the MAC address of your Thomson Gateway and enter it in the command. 2 Check the result. Execute the following CLI commands to verify whether the proxy-ARP entry has been added:
=>:ip arplist Interface 2 lan1 ... =>
IP-address 202.202.203.1
Check Connectivity
From now on, all clients should be able to connect to the Internet. As an initial test, try to send a ping to the default gateway that is set on the clients (202.202.203.1 in case of this scenario).
19
E-DOC-CTC-20051017-0157 v2.0
Chapter 4
If the current level is not as desired, execute the following CLI command to correct this:
:firewall level set name=Disabled
It is very important to know that firewall level Disabled does not mean the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually, the level Disabled means that all traffic coming in on one interface and going out on another is allowed. Nevertheless, the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients only. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and other stay enabled as well - as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
E-DOC-CTC-20051017-0157 v2.0
20
Chapter 5
Introduction
In some scenarios it might be interesting to implement a (semi-) dynamic public subnet model. On top of the basic functionality offered by PPP such as authentication, peer configuration and accounting, an extension is also available to dynamically offer a whole subnet to the PPP client. It is described how to enable this feature on a Thomson Gateway, and how the distribution of the subnet towards the other devices has to be handled.
5.1
Concept
Scenario Overview
In this chapter, the configuration of how to use the PPP IPCP subnet-mask option is explained. This functionality offers the dynamic configuration of the local public subnet by means of PPP IPCP configuration options exchanged during the setup of the PPP session. A conceptual example is shown in the figure below:
Calculates subnet (1 > n) > Uses MyIP1 for itself > Populates DHCP server with MyIP2 > MyIPn
Web
Internet
1 PVC
DHCP server
My Public Subnet
BAS
GW
Proxy
Figure 7 Concept drawing of subnet with IPCP subnet mask option When dialling into the network via PPP, the Thomson Gateway will not only receive its usual PPP parameters such as IP address, gateway address and DNS. The IPCP subnet mask option will also be included during the IPCP negotiation process. This parameter contains the subnet mask of the network the peer can use. By combining the IP address and the subnet-mask, the Thomson Gateway can derive what the boundaries are (start / end addresses) of the subnet that is offered. The first address of the subnet will be used by the Thomson Gateway itself. We will choose to put the address on the PPP interface rather than assign it to the local interface of the Thomson Gateway. The reason is to avoid all kinds of issues for traffic that will originate from the Thomson Gateway itself towards the WAN (such as ICMP, SNMP traps,...). In a dynamic model, the source-IP address selection for an unnumbered interface (as used in chapter 3.2 on page 14) is difficult to control. The rest of the IP addresses from the subnet will be put in a DHCP pool and offered on the local LAN segment. The DHCP clients will receive the IP address of the BAS as default gateway. To allow this construction to work, a proxy-ARP entry for this IP address will be automatically added to the Thomson Gateway configuration when the PPP session is established.
21
E-DOC-CTC-20051017-0157 v2.0
Chapter 5
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
IPCP Offer IP@: 202.202.203.16 Mask: 29 Gateway: 202.202.202.1 DHCP server 202.202.203.17 202.202.203.18 ... 202.202.203.22
202.202.203.17
Internet
PVC: 8/35
202.202.203.18
202.202203.19
Figure 8 Scenario example of subnet with IPCP subnet mask option The following sections will describe all configuration steps needed:
To...
Configure the DHCP Server Create the Uplink Interface Create the Uplink Interface Verify the Connection
See page...
23 24 24 26
E-DOC-CTC-20051017-0157 v2.0
22
Chapter 5
5.2
Practical Realisation
Adjust the lease time of the DHCP pool that has second priority to a low value. In this example we make use of the pool that is available by default on the Thomson Gateway, named LAN_private. When the PPP link is not up, all local hosts (being DHCP clients) will receive an address from this pool. As soon as the link is up and the DHCP pool IPCP_pool is populated, the clients will get a public address. To make sure this change does not take too long, lease times should be kept low. A DHCP client will check whether its lease is still valid after half of its lease time. In the current scenario we will configure that every 30 seconds, each DHCP client will check whether its lease is still valid. If the IPCP_pool in the meantime contains addresses, a lease from that pool will be offered instead of (re-)approving the old lease. Execute the following CLI commands to set the lease time of the default pool to 60 seconds:
:dhcp server pool config name=LAN_private leasetime=60
Make sure the DHCP server is running. Execute the following CLI command to check the status of the DHCP server:
=>:dhcp server config State: enabled
23
E-DOC-CTC-20051017-0157 v2.0
Chapter 5
Create a PPP interface. The configuration of the PPP interface requires some specific parameters for the subnet mask option. Therefore, it will be split-up in the basic part and the subnet mask specific part. Execute the following commands to create the PPP interface:
:ppp ifadd intf=ppp_MyPPP :ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword
The values MyUsername and MyPassword are to be replaced by the actual PPP connection credentials that are offered by your ISP. 3 Enable IPCP subnet masking. Execute the following CLI commands to set all necessary parameters of the PPP interface to activate IPCP subnet masking:
:ppp ifconfig intf=ppp_MyPPP format=cidr pool=IPCP_pool
As the PPP IPCP subnet mask option is not completely standardised, both dotted, noted as e.g. 255.255.255.0 and cidr (Classless Inter-Domain Routing), noted as e.g. /24 (also referred to as masked) notations of the subnet mask parameter are supported. 4 Enable the PPP interface. Execute the following CLI command to enable the PPP interface:
:ppp ifattach intf=ppp_MyPPP
E-DOC-CTC-20051017-0157 v2.0
24
Chapter 5
If the current level is not as desired, execute the following CLI command to correct this:
:firewall level set name=Disabled
It is very important to know that the firewall level Disabled does not mean the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually, the level Disabled means that all traffic coming in on one interface and going out on another, is allowed. But still the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and others stay enabled as well - as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
25
E-DOC-CTC-20051017-0157 v2.0
Chapter 5
Verify that the connection is established by the parameter oper state, which has to be up, and the parameter link state, which has to be connected. 2 Execute the following CLI command to verify the IP interfaces on the Thomson Gateway:
=>:ip iplist Interface 5 guest1 4 dmz1 2 lan1 1 ppp_MyPPP 0 loop =>
Verify that a new (public) IP address is configured on interface ppp_MyPPP, and no extra IP address is configured on any other of the LAN interfaces. 3 Execute the following CLI command to check the content of the DHCP pool:
=>:dhcp server pool list name=IPCP_pool Pool Start End 0 IPCP_pool 202.202.203.17 202.202.203.22 DHCP server Netmask Leasetime Gateway DNS domain DNS metric = = = = = = 192.168.1.254 [unnumbered] 255.255.255.248 60 202.202.203.1 lan 0
Intf lan1
State UP
Verify that the public IP addresses are available in the DHCP pool. The range should begin behind the IP address that is located on the PPP interface (as seen in the previous step). 4 Connect a client to the local subnet and see whether it receives an IP address from the DHCP pool with public IP addresses. When an address is received, the client should be able to make any connection to the internet.
E-DOC-CTC-20051017-0157 v2.0
26
Chapter 6
Multi-NAT
Introduction
With Multi-NAT, pure NAT is applied, meaning that there is a 1-1 relation between a private and public address. The Multi in Multi-NAT means that this 1-1 relation does not have to be defined in advance, hence there can be more private hosts than public IP addresses. The relation will be made at the first packet sent. From then on, a specific public address is reserved for the related private host.
6.1
Concept
Scenario Overview
Another way of handling multiple IP addresses is to make them available to private hosts by means of NAT. A possible implementation is to make a mapping between an internal and external IP address. Two different flavours exist: N-N NAT, where a chosen range of inside hosts (N inside IP addresses) can be mapped to an equal range of outside IP addresses (N outside IP addresses) for inbound and outbound traffic. M-N NAT, also called Multi-NAT, where a chosen set of inside hosts (M inside IP addresses) can be mapped to a set of outside IP addresses (N outside IP addresses) for outbound traffic only. This feature is called Many-to-Few NAT (where M is bigger than N). As M-N NAT is a more realistic approach, we will focus on that scenario.
NAT configuration: PubIP_X > PubIP_Y are available for PrivateIP_A > PrivateIP_Z First come, first served
PrivateIP_A
Internet
1 PVC
Private subnet
GW PrivateIP_B
PrivateIP_C
Figure 9 Concept drawing of M-N NAT In the figure above you see that there is no strict relation between an internal (private) IP address and the public IP addresses. There just is a range of public IP address (N) available for use to perform NAT on another range of private addresses (M). This is also the reason why no inbound (WAN to LAN) sessions can be instantiated. The relation between a public IP address and a private IP address is only made when a private host makes a connection to the public network.
27
E-DOC-CTC-20051017-0157 v2.0
Chapter 6
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
192.168.1.1
Internet
PVC: 8/35
BAS 202.202.203.1
GW 202.202.203.16 202.202.203.17
192.168.1.2
192.168.1.3
Figure 10 Scenario example of M-N NAT The following sections will describe all configuration steps needed:
To...
Create the Uplink Interface Define M-N NAT Set the Correct Firewall Level
See page...
29 30 30
E-DOC-CTC-20051017-0157 v2.0
28
Chapter 6
6.2
Practical Realisation
Create an Ethernet interface. Execute the following CLI commands to create Ethernet interface eth_MyETHoA:
:eth ifadd intf=eth_MyETHoA :eth ifconfig intf=eth_MyETHoA dest=atm_MyETHoA :eth ifattach intf=eth_MyETHoA
Create an IP interface. Execute the following CLI commands to create IP interface IP_MyETHoA and assign the two public IP addresses to it:
:ip :ip :ip :ip ifadd intf=ip_MyETHoA dest=eth_MyETHoA ipadd intf=ip_MyETHoA addr=202.202.203.16/24 addroute=enabled ipadd intf=ip_MyETHoA addr=202.202.203.17/24 addroute=enabled ifattach intf ip_MyETHoA
For IPoA interfaces it is even not necessary to configure the IP addresses on the IP interface, as they can be used in unnumbered mode. This technique will be used in 9 Public IP address Distribution by Hyper-NAT on page 40. 4 Create a route to the Internet. Execute the following CLI commands to inject a default route into the routing table:
:ip rtadd dst=0.0.0.0/0 gateway=202.202.203.1
29
E-DOC-CTC-20051017-0157 v2.0
Chapter 6
Execute the following CLI command to configure the M-N NAT that maps all internal addresses to the two public IP addresses:
:nat mapadd intf=ip_MyETHoA type=nat outside_addr=202.202.203.[1617] access_list=192.168.1.[1-153]
The access_list parameter is not required. It only restricts the use of this NAT-entry to a certain range of internal IP addresses. Be aware that in this configuration the Thomson Gateway will not be able to send traffic itself, as its IP address is not within the range of the access-list.
If your current level is not Standard or any higher-security level, execute the following CLI command:
:firewall level set name=Medium
For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
E-DOC-CTC-20051017-0157 v2.0
30
Chapter 7
Transparent NAT
Introduction
This type of NAT is mostly used in combination with other flavours, as it is quite a special one. The strange thing is actually that no NAT is performed; the packets are transparently forwarded from the public into the private segment of the network, where a host is configured with that particular public IP address. This feature is useful in cases where an interface is in NAT mode, but some of the IP addresses on it should not be translated. In that case, for these IP addresses, a transparent NAT entry should be defined.
7.1
Concept
Scenario Overview
As mentioned above, in the case of transparent NAT, no NAT is performed. This can be useful when NATunfriendly protocols are used by certain devices in the internal network. A good example are devices that use secure communication and do not allow a change in the packets they exchange. In this case the public IP address should be available on the device in the private network. A common example of a NAT unfriendly protocol is IPSec AH (Authentication Header). AH is a possible use of the IPSec protocol where most of the IP packet is signed, including the IP source and destination address. This means that if NAT would change the IP addresses in the IP header, the signature check would fail at the destination. When using IPSec AH, it is mandatory to have a public IP address on both sides of the tunnel. A conceptual example is shown in the figure below:
PubIP_X
Internet
1 PVC
Private subnet
GW PubIP_Y
PrivateIP_C
Figure 11 Concept drawing of transparent NAT With transparent NAT, it is mandatory to have a one-to-one link between an internal and the external IP address. Quite logical, as both IP addresses are equal! This implies that with transparent NAT connections can be established both inbound and outbound. For more information about the Thomson Gateway and Network Address Translation, see the Thomson Gateway Hyper-NAT Configuration Guide.
31
E-DOC-CTC-20051017-0157 v2.0
Chapter 7
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
202.202.203.16
Internet
PVC: 8/35
BAS 202.202.203.1
GW 202.202.203.16 202.202.203.17
202.202.203.17
192.168.1.3
Figure 12 Scenario example of transparent NAT The following sections will describe all configuration steps needed:
To...
Create the Uplink Interface Define Transparent NAT Set the Correct Firewall Level
See page...
33 34 35
E-DOC-CTC-20051017-0157 v2.0
32
Chapter 7
7.2
Practical Realisation
Create an Ethernet interface. Execute the following CLI commands to create Ethernet interface eth_MyETHoA:
:eth ifadd intf=eth_MyETHoA :eth ifconfig intf=eth_MyETHoA dest=atm_MyETHoA :eth ifattach intf=eth_MyETHoA
Create an IP interface. Execute the following CLI commands to create IP interface IP_MyETHoA and assign the two public IP addresses to it:
:ip :ip :ip :ip ifadd intf=ip_MyETHoA dest=eth_MyETHoA ipadd intf=ip_MyETHoA addr=202.202.203.16/24 addroute=enabled ipadd intf=ip_MyETHoA addr=202.202.203.17/24 addroute=enabled ifattach intf ip_MyETHoA
For IPoA interfaces it is even not necessary to configure the IP addresses on the IP interface, as they can be used in unnumbered mode. This technique will be used in 9 Public IP address Distribution by Hyper-NAT on page 40. 4 Create a route to the Internet. Execute the following CLI commands to inject a default route into the routing table:
:ip rtadd dst=0.0.0.0/0 gateway=202.202.203.1
33
E-DOC-CTC-20051017-0157 v2.0
Chapter 7
Define the Transparent NAT entry. Execute the following CLI command to enable transparent NAT on our IPoEoA interface for both public IP addresses:
:nat mapadd intf=ip_MyETHoA type=nat outside_addr=202.202.203.[1617] inside_addr=202.202.203.[16-17]
The inside_addr parameter defines which external IP address is related to which internal IP address. There will always be a one-on-one relation between an external address and an internal address. In case ranges of IP addresses are used, the first entry of both ranges map to each other, the second maps to the second, and so on. 3 Add routes to the internal hosts with public IP addresses. To make sure that arriving packets are forwarded correctly, we will have to explicitly define the Thomson Gateway interface via which our public hosts are reachable. Execute the following CLI command to the routes to the public hosts:
:ip rtadd dst=202.202.203.16/32 intf=lan1 :ip rtadd dst=202.202.203.17/32 intf=lan1
Enable Proxy-ARP for the default gateway. The transparent hosts will have the public IP addresses manually configured, and also use the IP address of the BAS as their default gateway. To allow the local transparent hosts to reach their default gateway, we need to add a Proxy-ARP entry in the Thomson Gateway. Execute the following CLI command to define the Proxy-ARP entry:
:ip arpadd intf=lan1 ip=202.202.203.1 hwaddr=$_MACADDR
E-DOC-CTC-20051017-0157 v2.0
34
Chapter 7
If the current level is not as desired, execute the following CLI command to correct this:
:firewall level set name=Disabled
It is very important to know that the firewall level Disabled does not mean that the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually, the level Disabled means that all traffic coming in on one interface and going out on another, is allowed. Nevertheless, the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and others stay enabled as well- as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
35
E-DOC-CTC-20051017-0157 v2.0
Chapter 8
X+n NAT
Introduction
This feature can be useful when a range of IP addresses has to be dynamically assigned to a certain customer, but the protocol used for the dynamic distribution (typically PPP-IPCP) does not support offering more than 1 IP address (note that the IPCP subnet mask option is not standardised, thus not available in all devices). In some implementations it defined that if IP address X is offered, the next n IP addresses are also available for use. To handle this kind of forced IP range definitions, the use of N+x NAT templates is needed.
8.1
Concept
Scenario Overview
In this scenario only one IP address is offered to the Thomson Gateway by means of dynamic configuration (DHCP or PPP). Both the Thomson Gateway and the BAS, however, are defined so that the next n IP addresses can also be used, where number n is statically configured on both the BAS and the Thomson Gateway. A conceptual example is shown in the figure below:
BAS offers 1 address (IPx) but assigns a range in its routing table.
Receives only 1 address but knows by configuration that it can use a range.
PrivateIP_A
PrivateIP_B
PrivateIP_C
Figure 13 Concept drawing of X+n NAT To enable this kind of configuration, one can choose between: N-N NAT, where a static link exists between the internal IP addresses and the public IP addresses. In this case that might sound strange, as the public IP addresses are dynamically assigned to the Thomson Gateway. The static link here means that for example PrivateIP_A will always be mapped to the first address of the available range, PrivateIP_B to the second of the range and so on. Multi-NAT, where the internal addresses will be mapped to a public IP address from the moment the internal host starts a connection. For example, when the host with PrivateIP_B initiates the first connection, it will be mapped to the first IP address from the available range. For more information about the Thomson Gateway and Network Address Translation, see the Thomson Gateway Hyper-NAT Configuration Guide.
E-DOC-CTC-20051017-0157 v2.0
36
Chapter 8
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
192.168.1.1
192.168.1.2
192.168.1.3
Figure 14 Scenario example of X+n NAT In this scenario we will make use of N-N NAT. The following sections will describe all configuration steps needed:
To...
Create the Uplink Interface Define X+n NAT Set the Correct Firewall Level
See page...
38 38 39
37
E-DOC-CTC-20051017-0157 v2.0
Chapter 8
8.2
Practical Realisation
Create a PPP interface. Execute the following CLI commands to create PPP interface ppp_MyPPP:
:ppp ifadd intf=ppp_MyPPP :ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword
Define the default route Execute the following CLI commands to inject a default route into the routing table from the moment the PPP link is connected and the IP negotiation was successful:
:ppp rtadd intf=ppp_MyPPP dst=0.0.0.0/0
In this case we do not define a NAT mapping but a NAT template. This is needed because of the dynamic behaviour of the PPP interface that we are using. A NAT template is automatically established (creates an actual NAT mapping) from the moment it receives IP parameters.
E-DOC-CTC-20051017-0157 v2.0
38
Chapter 8
If the current level is not as expected, execute the following CLI command:
:firewall level set name=Disabled
It is very important to know that firewall level Disabled does not mean the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually, the level Disabled means that all traffic coming in on one interface and going out on another, is allowed. Nevertheless, the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and other stay enabled as well - as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
39
E-DOC-CTC-20051017-0157 v2.0
Chapter 9
Introduction
The Thomson Gateway Hyper-NAT implementation offers many types of NAT configuration. One of the powerful capabilities of Hyper-NAT is that all these different NAT flavours can be used in a mixed mode. This can be very interesting in case a user has a range of public IP addresses available, and wants to use each one of them to fulfil a specific need.
9.1
Concept
Scenario overview
In this scenario we have multiple public IP addresses that are available for our use. We will make use of Thomson Gateway Hyper-NAT to assign each one of them to a specific service the local network. A conceptual example is shown in the figure below:
NAT configuration: PubIP_X: Basic NAPT for LAN PCs PubIP_Y: N-N NAT for Web in LAN >> IP@ of server can stay as before PubIP_Z: Transparent NAT for IPSec GW >>Public IP@ for VPN GW at public side to avoid NAT issues
PCs
Internet
1 PVC
Private subnet
BAS
IPSEC GW
Figure 15 Concept drawing address distribution by Hyper-NAT A typical example could be: Use one of the IP addresses to offer shared internet access to all normal internal hosts (PCs), by using regular NAPT on this IP address. Link public IP addresses to the internal servers by N-N NAT entries, and as such avoid IP reconfiguration on these hosts. Use transparent NAT entries to link to internal servers which use protocols that cannot handle IP address translation (as IPSec AH). For more information about the Thomson Gateway and Network Address Translation, please refer to the Thomson Gateway Hyper-NAT Configuration Guide R5.3.0.
E-DOC-CTC-20051017-0157 v2.0
40
Chapter 9
Scenario
The following pages will show how to configure the Thomson Gateway when you have to connect to this type of network configuration. The goal will be to integrate the Thomson Gateway in the following network structure:
NAT configuration: 202.202.203.16 > NAPT for local PCs 202.202.203.17 > 192.168.1.200 (Webserver) 202.202.203.18 > 202.202.203.18 (IPSEC GW)
PCs 192.168.1.x
Internet
PVC: 8/35
Private subnet
GW Webserver 192.168.1.200
Figure 16 Scenario example of address distribution by Hyper-NAT In this scenario we will make use of an unnumbered PPP connection as WAN link, with static IP address configuration. The following sections will describe all configuration steps needed:
To...
Create the Uplink Interface Define NAT Entries Set the Correct Firewall Level
See page...
42 43 44
41
E-DOC-CTC-20051017-0157 v2.0
Chapter 9
9.2
Practical Realisation
Create a PPP interface. Execute the following CLI commands to create PPP interface ppp_MyPPP:
:ppp ifadd intf=ppp_MyPPP :ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword unnumbe red=enabled
The values MyUsername and MyPassword are to be replaced by the actual PPP connection credentials that are offered by your ISP 3 Define the default route. Execute the following CLI commands to inject a default route into the routing table from the moment the PPP link is connected and the IP negotiation was successful:
:ppp rtadd intf=ppp_MyPPP dst=0.0.0.0/0
Connect the PPP interface. Execute the following CLI command to enable the PPP interface:
:ppp ifattach intf=ppp_MyPPP
E-DOC-CTC-20051017-0157 v2.0
42
Chapter 9
An optional parameter when configuring a NAT mapping is the accesslist, allowing to restrict the use of the NAPT mapping. The Thomson Gateway WAN interface is unnumbered and will select the primary IP address of the primary IP interface as source IP address for packets sent out by itself on the WAN interface. In this scenario, a private IP address will be used initially, and it should be translated to a public IP address by the NAT engine. Make sure when restricting the applicability of NAT mappings, that this primary IP address is also within the range of one of the NAT mappings defined. 2 Configure the 1-1 NAT mapping for the web server. The public IP address 202.202.203.17 will be mapped to the internal web server with local IP address 192.168.1.200. Making an exclusive link between a public and private IP address has to be done by defining a 1-1 NAT mapping. Execute the following CLI command to create this 1-1 NAT mapping:
:nat mapadd intf=ppp_MyPPP type=nat outside_addr=202.202.203.17 inside_addr=192.168.1.2 00
Transparent NAT mapping for the IPSec server. The public IP address 202.202.203.18 has to be transparently forwarded towards the IPSec server which is located in the private network. Despite the fact that this server is located in the private network, it has the public IP address 202.202.203.18 configured. Apart from the public IP address, a private IP address could also be configured on the server, via multi-homing techniques or other techniques, depending on the capabilities of the Operating System. Execute the following CLI command to create the transparent NAT entry:
:nat mapadd intf=ppp_MyPPP type=napt outside_addr=202.202.203.18 inside_addr=202.202.20 3.18
In transparent mode, the packet is transparently forwarded without translation. That means that the forwarding table needs information on how to reach the transparent host. Execute the following CLI commands to define where the transparent host is located:
:ip rtadd dst=202.202.203.18/32 intf=lan1
The transparent host will have a public IP addresses configured, and also use the public gateway (in this scenario the IP address of the BAS). To allow this host to reach its default gateway, we need to add a Proxy-ARP entry in the Thomson Gateway. Execute the following CLI command to define the Proxy-ARP entry:
:ip arpadd intf=lan1 ip=202.202.203.1 hwaddr=00-0E-50-34-00-F2
43
E-DOC-CTC-20051017-0157 v2.0
Chapter 9
If the current level is not as desired, execute following CLI command to correct this:
:firewall level set name=Disabled
It is very important to know that firewall level Disabled does not mean the complete Thomson Gateway firewall is disabled. A firewall level only applies to traffic that is forwarded by the Thomson Gateway. So actually, the level Disabled means that all traffic coming in on one interface and going out on another, is allowed. Nevertheless, the Thomson Gateway itself stays protected as it was before, meaning that access to the embedded system services of the Thomson Gateway (as telnet, web interface,...) are still only allowed for LAN originating clients. Apart from protecting the Thomson Gateway host itself, the statefull tracking, TCP checks and others stay enabled as well - as with any other firewall level that is chosen. For more information on how to configure the firewall to fulfil your specific needs, see the Thomson Gateway Statefull Inspection Firewall Configuration Guide.
Verify whether the connection is established. If it is, the parameter oper state has to be up, and parameter link state has to be connected.
E-DOC-CTC-20051017-0157 v2.0
44
Chapter 9
Inside Address
Use
202.202.204.11 0 202.202.204.11 any any Static Transparent Two-way NAT 0 192.168.1.200 0 192.168.1.200 any any Static Two-way NAT 0 unmapped 0 any any any Static Outbound NAPT without defserver 0
45
E-DOC-CTC-20051017-0157 v2.0
Visit us at:
www.thomson-broadband.com
Coordinates:
Thomson Telecom Prins Boudewijnlaan 47 B-2650 Edegem Belgium
Copyright
2008 Thomson. All rights reserved. The content of this document is furnished for informational use only, may be subject to change without notice, and should not be construed as a commitment by Thomson. Thomson assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. The information contained in this document represents the current view of Thomson on the issues discussed as of the date of publication. Because Thomson must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Thomson, and Thomson cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. Thomson MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.