AppNote multipubIPaddress

Thomson Gateways and Multiple IP Addresses
Date: Version:
June 2008 v2.0
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
Introduction.................................................................................. 4 Static Subnet with Numbered WAN Link ................................. 6

Scenario Overview .......................................................................................... 6 Practical Realisation ....................................................................................... 8
3
3.1 3.2
Static Subnet with Unnumbered WAN Link........................... 11

Scenario Overview ........................................................................................ 11 Practical Realisation ..................................................................................... 13
4
4.1 4.2
Static Subnet in Full Unnumbered mode................................ 16

5
5.1 5.2
Subnet with IPCP Subnet Mask Option .................................. 21

6
6.1 6.2
Multi-NAT ................................................................................... 27
7
7.1 7.2
Transparent NAT ....................................................................... 31

8
8.1 8.2
X+n NAT ..................................................................................... 36

9
9.1
Public IP address Distribution by Hyper-NAT ......................... 40

Scenario overview......................................................................................... 40
E-DOC-CTC-20051017-0157 v2.0
Contents
9.2
Practical Realisation ..................................................................................... 42
E-DOC-CTC-20051017-0157 v2.0
ii
Contents
iii
E-DOC-CTC-20051017-0157 v2.0
Chapter 1
Introduction
Purpose of this Application Note

This application note provides a guide on how to configure the Thomson Gateway in all kinds of different scenarios where multiple public IP addresses are to be used by the customer. The goal is to explain how the Thomson Gateway has to be configured in all these different scenarios. In practice, only one setup will be applicable, as the Thomson Gateway has to fit in a model that is imposed by the Service Provider.
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
Static Subnet with Numbered WAN Link
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).
IP addresses used for these networks can be private.
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
My Public Subnet 202.202.203.16/29
BAS Route: 202.202.203.16/29 > 172.16.5.57
GW Default Route > 202.202.202.1 202.202.203.18
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 the Uplink Interface

First of all, we have to create the WAN-interface that will be used to connect to the ISP. For this scenario we will use the IP over ATM (IPoA) connection service, often used in these kind of setups. The example will be configured with VPI/VCI values 8/35, using LLC/SNAP encapsulation. Using any other type of statically configured uplink interface does not impact the other steps during configuration. The only item to watch is that the IP address of the gateway and the route-IP have to be in the same subnet for non point-to-point connection models. This is not an issue for point-to-point connections, as they just need a local and remote IP address which are not bound to subnets. Proceed as follows: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyIPoA:
:atm :atm :atm :atm phonebook add name=phone_MyIPoA addr=8.35 ifadd intf=atm_MyIPoA ifconfig intf=atm_MyIPoA dest=phone_MyIPoA encaps=llc ulp=ip ifattach intf=atm_MyIPoA
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
Define the Local Public Subnet

All public IP addresses that were assigned to us by the ISP will have to be configured manually on each host. We will also assign one of the IP addresses of our public subnet to the Thomson Gateway. This IP address will serve as the gateway for all other hosts on our local public subnet. Execute the following CLI command to assign the IP address to the local Ethernet interface:
:ip ipadd intf=lan1 addr=202.202.203.22 netmask=255.255.255.248 addroute=enabled
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.
Define the Routing towards the Internet

Now that all IP addresses are configured, we have to define the routing towards the Internet. As the Thomson Gateway is acting as a pure router in this scenario, this is quite straightforward. Execute the following CLI command to inject a default route towards the Internet in the routing table:
:ip rtadd dst=0.0.0.0/0 gateway=202.202.202.1
Enable DNS Forwarding

Optionally, it is possible to let the Thomson Gateway act as the default DNS server for all local hosts. If the Thomson Gateway cannot resolve the DNS request from its own database, it will forward the request to a DNS server of your ISP. Execute the following CLI command to configure the external DNS server to which your Thomson Gateway can forward DNS queries that it cannot resolve by itself:
:dns server route add dns=202.204.54.20 intf=lan1
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
Set the Correct Firewall Level

In this setup, where both the LAN and WAN side of the Thomson Gateway are public, the firewall level should be set to Disabled. This will allow all inbound and outbound connections to pass the Thomson Gateway. However, when your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall so that it only allows connections that are initiated from the local network towards the public network. The Thomson Gateway by default has several levels defining that only outbound sessions can be made. This restriction starts from level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check the current level of your firewall:
=>:firewall level list Level Config ============ Active Level: Disabled ... =>
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
Static Subnet with Unnumbered WAN Link
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
202.202.203.17
No IP
202.202.203.22
Internet
PVC: 8/35
BAS 202.202.202.1 Route: 202.202.203.16/29 > IPoA...
GW Default Route > IP_MyIPoA 202.202.203.18
202.202.203.19
Figure 4 Scenario example of unnumbered WAN interface
The following sections describe all the configuration steps needed:
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

First of all, we have to create the WAN interface that will be used to connect to the ISP. For this scenario we will use the IP over ATM (IPoA) connection service. The example will be configured with VPI/VCI values 8/35, and using LLC/SNAP encapsulation. Using PPP as uplink interface does not impact the other steps to be done during the configuration. An example of unnumbered PPP configuration can be found in 4.2 Practical Realisation on page 18. Proceed as follows to create the IPoA uplink interface: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyIPoA:
:atm :atm :atm :atm phonebook add name=phone_MyIPoA addr=8.35 ifadd intf=atm_MyIPoA ifconfig intf=atm_MyIPoA dest=phone_MyIPoA encaps=llc ulp=ip ifattach intf=atm_MyIPoA
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

All public IP addresses that were assigned to us by the ISP will have to be configured manually on each host. We will assign one of the IP addresses of our public subnet to the Thomson Gateway. This IP address will serve as the gateway for all other hosts on our local public subnet. Next to the default gateway function, this IP address will offer the possibility to remotely access the Thomson Gateway. Execute the following CLI command to assign the IP address to the local Ethernet interface:
:ip ipadd intf=lan1 addr=202.202.203.22 netmask=255.255.255.248 addroute=enabled
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
Define the Routing towards the Internet

As described above, we can make use of a so called interface route instead of the usual gateway route in case of point-to-point connections. Execute the following CLI command to inject an interface based default route into the routing table:
:ip rtadd dst=0.0.0.0/0 intf=My_IPoA
Set the Default IP Address

When using an unnumbered interface, we have to take care of traffic generated by the Thomson Gateway itself on this interface. As the IP interface has no IP address assigned to it, the Thomson Gateway will have to use another IP address that is set on one of the other IP interfaces. When a packet is to be sent out on an unnumbered interface, the Thomson Gateway will automatically use the primary IP address of its primary IP interface as source IP address. Both of these parameters are configurable, which means that an interface can be set as the primary of all interfaces, and an IP address can be set to be the primary of all IP addresses (per interface, that is). For this scenario, it is important that the public IP address that will be assigned to the Thomson Gateway on the LAN-side is set to be the primary address of that interface. Secondly, the local IP interface that we use (in our scenario, it is IP interface lan1) has to be configured as the default interface of all IP interfaces. Execute the following CLI commands to set our local public IP address to be the primary IP address of the whole Thomson Gateway configuration:
:ip ipconfig addr=202.202.203.22 primary=enabled :ip ifconfig intf=lan1 primary=enabled
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 =>
Type Ethernet Ethernet Ethernet Ethernet Internal
IP-address *192.168.3.254 *192.168.2.254 *202.202.203.22 192.168.1.254 127.0.0.1
Point-to-point/Mask 255.255.255.0 255.255.255.0 255.255.255.248 255.255.255.0 255.255.255.255
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
Enable DNS Forwarding

Optionally, it is possible to let the Thomson Gateway act as the default DNS server for all local hosts. If the Thomson Gateway cannot resolve the DNS request from its own database, it will forward the request to a DNS server of your ISP. Execute the following CLI command to configure the external DNS server to which your Thomson Gateway can forward the DNS queries that it cannot resolve by itself:
:dns server route add dns=202.204.54.20 intf=lan1
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.

In this setup, where both the LAN and WAN side of the Thomson Gateway are public, the firewall level should be set to Disabled. This will allow all inbound and outbound connections to pass the Thomson Gateway. However, when your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall so that it only allows connections that are initiated from the local network towards the public network. The Thomson Gateway by default has several levels defining that only outbound sessions can be made. This restriction starts from level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check current level of your firewall:
If the current level is not as desired, execute the following CLI command to correct this:
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
Static Subnet in Full Unnumbered mode
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.
No IP No IP Proxy-ARP for Gatway IP@
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
202.202.203.17/24 Gateway: 202.202.203.1
No IP No IP Proxy-ARP for 202.202.203.1
Internet
PVC: 8/35
BAS 202.202.203.1 Route: 202.202.203.16/29 > PPP...
GW Default Route > IP_MyPPP 202.202.203.18/24 Gateway: 202.202.203.1
202.202.203.19/24 Gateway: 202.202.203.1
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

The current scenario allows the use of both IPoA and PPP interfaces. As an example we will make use of a PPP connection. Proceed as follows to create the PPP uplink interface: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyPPP:
:atm :atm :atm :atm phonebook add name=phone_MyPPP addr=8.35 ifadd intf=atm_MyPPP ifconfig intf=atm_MyPPP dest=phone_MyPPP encaps=vcmux ulp=ppp ifattach intf=atm_MyPPP
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

All public IP addresses that were assigned to us by the ISP will have to be configured manually on each host. As we will not assign any public IP address to the Thomson Gateway, it is not aware that the 202.202.203.16/ 29 subnet is used on the local segment. To make sure that arriving packets are forwarded correctly we will have to explicitly define via which interface of the Thomson Gateway our public subnet is reachable. Execute the following CLI command to inject a route into the routing table that defines our public subnet is reachable via interface lan1:
:ip rtadd dst=202.202.203.16/29 intf=lan1
Proxy ARP for the Gateway

All hosts on the local segment will have the IP address of the BAS (Gateway) set as their default gateway. As the local segment is not directly connected to the BAS, we have to foresee a proxy-ARP entry in the Thomson Gateway for the IP address of the BAS, because ARP requests cannot pass routers. In case a host on the local segment wants to send traffic via its default gateway, it will first send an ARP request to resolve the MAC address that is related with the default gateway IP address. An ARP request is an Ethernet broadcast packet, which cannot pass a router. So by default, the ARP would never be able to reach the BAS. What actually happens with a proxy ARP entry, is that the Thomson Gateway will present itself as if it has the IP address of the BAS. The result is that if there is an ARP request for the IP address of the BAS on the local Ethernet segment, our Thomson Gateway will answer the ARP request with its own MAC address. The local device will then start sending its packets with the Ethernet destination set to the MAC address of our Thomson Gateway. Subsequently, the Thomson Gateway will process the packets as if they were any other packet, meaning that they will be routed to the BAS. Proceed as follows to make the Thomson Gateway proxy ARP for the BAS IP address: 1 Create the Proxy-ARP entry. Execute the following CLI command to configure the proxy ARP for the IP address of the BAS:
:ip arpadd intf=lan1 ip=202.202.203.1 hwaddr=$_MACADDR
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
HW-address Type 00:0e:50:34:00:f2 PROXY
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

In this setup, where both the LAN and WAN side of the Thomson Gateway are public, the firewall level should be set to Disabled. This will allow all inbound and outbound connections to pass the Thomson Gateway. However, when your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall to only allow connections that are initiated from the local network towards the public network. The Thomson Gateway by default has several levels defining that only outbound sessions can be made. This restriction starts from level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check the current level of your firewall:
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
Subnet with IPCP Subnet Mask Option
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:
PPP server Offers IPCP subnetmask
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
Mail
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
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
BAS 202.202.202.1 Route: 202.202.203.1.16/29 > PPP
GW 202.202.203.16 Default Route > PPP intf
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
Configure the DHCP Server

Proceed as follows: 1 Create a new DHCP pool via which the IPCP subnet will be made available on the local network segment. Enter the following CLI commands to create the DHCP pool:
:dhcp server pool add name=IPCP_pool index=0 :dhcp server pool config name=IPCP_pool leasetime=60 unnumbered=enabled
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
Execute the following command to enable the DHCP server if needed:

:dhcp server config state enabled
23
E-DOC-CTC-20051017-0157 v2.0
Chapter 5

Create the WAN interface that will be used to connect to the ISP, which is PPP in the current scenario. Whether the PPP protocol runs directly on top of ATM (PPPoA) or with an Ethernet layer in between (PPPoE), is completely transparent for the IPCP subnet mask option. The example will be configured with VPI/VCI values 8/35, VCMUX encapsulation, using the PPPoA connection service. Proceed as follows: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyPPP:
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:
E-DOC-CTC-20051017-0157 v2.0
24
Chapter 5

In this setup, where both the LAN and WAN side of the Thomson Gateway are public, the firewall level should be set to Disabled. This will allow all inbound and outbound connections to pass the Thomson Gateway. However, when your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall so that it only allows connections that are initiated from the local network towards the public network. The Thomson Gateway by default has several levels defining that only outbound sessions can be made. This restriction starts from level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check the current level of your firewall:
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 the Connection

Proceed as follows to see if the connection is working correctly: 1 Execute the following CLI command to check the status of the PPP interface:
=>:ppp iflist ppp_MyPPP: dest : atm_MyPPP [00:06:13] Retry : 10 mode = IP unnumbered + DHCP [-> IPCP_pool] flags = echo magic accomp restart mru addr savepwd chap [.] dns metric = 0 mru = 1500 RxTx inactivity = 60s left = 0s auth = auto user = MyUsername password = ******** admin state = up oper state = up link state = connected LCP : state = opened retransm = 0 term. reason = IPCP: state = opened retransm = 10 term. reason = =>
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 =>
Type Ethernet Ethernet Ethernet Serial Internal
IP-address *192.168.3.254 *192.168.2.254 *192.168.1.254 202.202.203.16 127.0.0.1
Point-to-point/Mask 255.255.255.0 255.255.255.0 255.255.255.0 202.202.203.1 255.255.255.255
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
DNS address list: 192.168.1.254 (local DNS) 202.204.254.20 =>
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
BAS 2 public IP addresses > PubIP_X > PubIP_Y
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
NAT configuration: 202.202.203.[16..17] available for 192.168.1.[1..253]
192.168.1.1
Internet
PVC: 8/35
My Private Subnet 192.168.1.1/24
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

First of all, we have to create the WAN-interface that will be used to connect to the ISP, which in the current scenario is IPoEoA (IP over Ethernet over ATM, also referred to as ETHoA or MER). We will create one IPoEoA interface and assign two public IP addresses to it. Using any other type of statically configured uplink interface does not impact the other steps to be done during the configuration. Proceed as follows: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyETHoA:
:atm :atm :atm :atm phonebook add name=phone_MyETHoA addr=8.35 ifadd intf=atm_MyETHoA ifconfig intf=atm_MyETHoA dest=phone_MyETHoA encaps=llc ulp=mac ifattach intf=atm_MyETHoA
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:
29
E-DOC-CTC-20051017-0157 v2.0
Chapter 6
Define M-N NAT

To proceed we have to create the NAT entry that will enable the M-N NAT functionality. We will use the by default available private subnet of IP range 192.168.1.1/24. Execute the following CLI command to enable NAT on our IPoEoA interface:
:nat ifconfig intf=ip_MyETHoA translation=enabled
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.

In this setup, where no link exists between the public IP addresses and the internal hosts until an outbound session is made, we could state that the model implicates that the local hosts are always clients. When your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall so that it only allows connections that are initiated from the local network towards the public network. By default, the Thomson Gateway has several levels defining that only outbound sessions can be made. This restriction starts from the level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check current level of your firewall:
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:
NAT configuration: PubIP_[X..Y] should be forwarded transparantly towards PubIP_[X..Y]
PubIP_X
Internet
1 PVC
Private subnet
BAS 2 public IP addresses > PubIP_X > PubIP_Y
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
NAT configuration: 202.202.203.[16..17] to be forwarded transparantly to 202.202.203.[16..17]
202.202.203.16
Internet
PVC: 8/35
My Private Subnet 192.168.1.1/24
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

First of all, we will have to create the WAN-interface that will be used to connect to the ISP, which in the current scenario is IPoEoA (IP over Ethernet over ATM, also referred to as ETHoA or MER). We will create one IPoEoA interface and assign two public IP addresses to it. Using any other type of statically configured uplink interface does not impact the other steps during the configuration. Proceed as follows: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyETHoA:
:atm :atm :atm :atm phonebook add name=phone_MyETHoA addr=8.35 ifadd intf=atm_MyETHoA ifconfig intf=atm_MyETHoA dest=phone_MyETHoA encaps=llc ulp=mac ifattach intf=atm_MyETHoA
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:
33
E-DOC-CTC-20051017-0157 v2.0
Chapter 7
Define Transparent NAT

In order to proceed, we have to configure the transparent NAT entry. Proceed as follows to enable transparent NAT on our interface: 1 Enable NAT on the interface. Execute the following CLI commands to enable NAT on interface ip_MyETHoA:
:nat ifconfig intf=ip_MyETHoA translation=enabled
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

In this setup, where both the LAN and WAN side of the Thomson Gateway are public, the firewall level should be set to Disabled. This will allow all inbound and outbound connections to pass the Thomson Gateway. However, when your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall to only allow connections that are initiated from the local network towards the public network. The Thomson Gateway by default has several levels defining that only outbound sessions can be made. This restriction starts from level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check the current level of your firewall:
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
Private Subnet Internet

1 PVC
BAS Route: IP[x..x+n] > interface to GW
GW Route: Default > interface to BRAS
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
Offer IP@: 202.202.203.16 Gateway: 202.202.202.1 ...
N-N NAT 202.202.203.[16..22] >> 192.168.1.[1..7]
192.168.1.1
Private Subnet Internet

PVC: 8/35
BAS Route: 202.202.203.[16..22] > PPP
GW 202.202.203.16 Default Route > PPP intf
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

Create the WAN-interface that will be used to connect to the ISP. In current scenario we will make use of the PPP connection model. Whether the PPP protocol runs directly on top of ATM (PPPoA) or with an Ethernet layer in between (PPPoE) is completely transparent. The use of another type of dynamic interface, such as a DHCP client on top of an ETHoA interface, does not make a difference for the X+n mapping that will be made. The example will be configured with VPI/VCI values 8/35, VCMUX encapsulation, using the PPPoA connection service. Proceed as follows: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyPPP:
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:
Define X+n NAT

The next step is to create the X+n NAT entry that will enable N-N NAT for n addresses. For the private range, we will use the subnet available by default. The local hosts with the IP addresses 192.168.1.1 to 192.168.1.6 will get connectivity through N-N NAT. Execute the following CLI command to configure the X+n NAT entry:
:nat tmpladd intf=ppp_MyPPP type=nat outside_addr=0.0.0.[1-6] inside_addr=192.168.1.[1-6]
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

In this setup, the firewall level depends on the specific situation: In the case of changing IP addresses, even though there is a one-to-one link between each public and each private address, it does not make a lot of sense to regard it as a regular situation where both inbound and outbound sessions are allowed. As the IP addresses might change regularly, it seems unlikely that services will run on the local hosts. For that reason, we could state that all local hosts are clients, and that they are expected to establish all connections. Therefore, a firewall level that only permits outbound connections (as Normal or a higher security level) might be more appropriate. When the ISP always offers the same IP addresses, there are no more restrictions to actually run services on the local hosts. In this case also inbound connections should be possible. To allow all inbound connections the firewall level should be set to Disabled. Execute the following CLI command to check the current level of your firewall:
If the current level is not as expected, execute the following CLI command:
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.
Enable the Dynamic Connection

Now that all these configuration steps are completed, we can enable the connection. If the PPP interface connects before the creation of the NAT templates, no NAT mappings will be established. Execute the following CLI command to make the PPP interface dial-in:
39
E-DOC-CTC-20051017-0157 v2.0
Chapter 9
Public IP address Distribution by Hyper-NAT
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
GW Webserver Any link type, static configuration
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
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
BAS 202.202.203.16/29 > PPP link
GW Webserver 192.168.1.200
IPSEC GW 202.202.203.18 192.168.1.210
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

Create the WAN interface that will be used to connect to the ISP. In the current scenario we will make use of the unnumbered PPP connection model. It is completely transparent whether the PPP protocol runs directly on top of ATM (PPPoA) or with an Ethernet layer in between (PPPoE). The example will be configured with VPI/VCI values 8/35, VCMUX encapsulation, using the PPPoA connection service. Proceed as follows: 1 Create an ATM interface. Execute the following CLI commands to create ATM interface atm_MyPPP:
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:
Connect the PPP interface. Execute the following CLI command to enable the PPP interface:
E-DOC-CTC-20051017-0157 v2.0
42
Chapter 9
Define NAT Entries

Proceed as follows to configure the NAT entries that will handle all different public IP addresses: 1 Configure the NAPT mapping for shared internet access. Public IP address 202.202.203.16 will be used to share internet access for the local PCs. These PCs have internal IP addresses ranging from 192.168.1.1 up to 192.168.1.199. This functionality can be achieved by creating a NAPT mapping. Execute the following CLI command to create this NAPT mapping:
:nat mapadd intf=ppp_MyPPP type=napt outside_addr=202.202.203.16
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

In this setup, where both the LAN and WAN side of the Thomson Gateway are public, the firewall level should be set to Disabled. This will allow all inbound and outbound connections to pass the Thomson Gateway. However, when your local hosts are not supposed to offer services towards the public network, it is safer to configure the firewall so that it only allows connections that are initiated from the local network towards the public network. The Thomson Gateway by default has several levels defining that only outbound sessions can be made. This restriction starts from level standard and is valid for all higher-security firewall levels. Execute the following CLI command to check current level of your firewall:
=>:firewall level list Level Config ============ Active Level: Disabled ...
If the current level is not as desired, execute following CLI command to correct this:
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 the Connection

Proceed as follows to see if the connection is working: 1 Execute the following CLI command to check the status of the PPP interface:
=>:ppp iflist ppp_MyPPP: dest: atm_MyPPP [00:06:13] Retry : 10 mode = IP unnumbered + DHCP [-> IPCP_pool] flags = echo magic accomp restart mru addr savepwd chap [.] dns metric = 0 mru = 1500 RxTx inactivity = 60s left = 0s auth = auto user = cpesit@cisco password = ******** admin state = up oper state = up link state = connected LCP : state = opened retransm = 0 term. reason = IPCP: state = opened retransm = 10 term. reason =
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
Execute the following CLI command to verify the NAT mappings:

=>:nat maplist expand=enabled Idx Type Interface Outside Address ... 5 NAT ppp_MyPPP 202.202.204.11 Access List............... Foreign Address........... Protocol.................. Flags..................... Description............... Creator Data.............. 6 NAT ppp_MyPPP 202.202.204.10 Access List............... Foreign Address........... Protocol.................. Flags..................... Description............... Creator Data.............. 7 NAPT ppp_MyPPP 202.202.204.9 Access List............... Foreign Address........... Protocol.................. Flags..................... Description............... Creator Data..............
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.

AppNote multipubIPaddress

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AppNote multipubIPaddress

Загружено:

Авторское право:

Доступные форматы

Thomson Gateways and Multiple IP Addresses

June 2008 v2.0

Introduction.................................................................................. 4 Static Subnet with Numbered WAN Link ................................. 6

Static Subnet with Unnumbered WAN Link........................... 11

Static Subnet in Full Unnumbered mode................................ 16

Subnet with IPCP Subnet Mask Option .................................. 21

Transparent NAT ....................................................................... 31

X+n NAT ..................................................................................... 36

Public IP address Distribution by Hyper-NAT ......................... 40

Practical Realisation ..................................................................................... 42

Purpose of this Application Note

Static Subnet with Numbered WAN Link

IP addresses used for these networks can be private.

My Public Subnet 202.202.203.16/29

BAS Route: 202.202.203.16/29 > 172.16.5.57

GW Default Route > 202.202.202.1 202.202.203.18

Create the Uplink Interface

Define the Local Public Subnet

Define the Routing towards the Internet

Enable DNS Forwarding

Set the Correct Firewall Level

Static Subnet with Unnumbered WAN Link

My Public Subnet 202.202.203.16/29

BAS 202.202.202.1 Route: 202.202.203.16/29 > IPoA...

GW Default Route > IP_MyIPoA 202.202.203.18

Figure 4 Scenario example of unnumbered WAN interface

The following sections describe all the configuration steps needed:

Create the Uplink Interface

Define the Local Public Subnet

Define the Routing towards the Internet

Set the Default IP Address

Type Ethernet Ethernet Ethernet Ethernet Internal

IP-address *192.168.3.254 *192.168.2.254 *202.202.203.22 192.168.1.254 127.0.0.1

Point-to-point/Mask 255.255.255.0 255.255.255.0 255.255.255.248 255.255.255.0 255.255.255.255

Enable DNS Forwarding

Set the Correct Firewall Level

Static Subnet in Full Unnumbered mode

No IP No IP Proxy-ARP for Gatway IP@

202.202.203.17/24 Gateway: 202.202.203.1

No IP No IP Proxy-ARP for 202.202.203.1

My Public Subnet 202.202.203.16/29

BAS 202.202.203.1 Route: 202.202.203.16/29 > PPP...

GW Default Route > IP_MyPPP 202.202.203.18/24 Gateway: 202.202.203.1

202.202.203.19/24 Gateway: 202.202.203.1

Create the Uplink Interface

Define the Local Public Subnet

Proxy ARP for the Gateway

HW-address Type 00:0e:50:34:00:f2 PROXY

Set the Correct Firewall Level

Subnet with IPCP Subnet Mask Option

PPP server Offers IPCP subnetmask

My Public Subnet 202.202.203.16/29

BAS 202.202.202.1 Route: 202.202.203.1.16/29 > PPP

GW 202.202.203.16 Default Route > PPP intf

Configure the DHCP Server

Execute the following command to enable the DHCP server if needed:

Create the Uplink Interface

Set the Correct Firewall Level

Verify the Connection

Type Ethernet Ethernet Ethernet Serial Internal

IP-address *192.168.3.254 *192.168.2.254 *192.168.1.254 202.202.203.16 127.0.0.1

Point-to-point/Mask 255.255.255.0 255.255.255.0 255.255.255.0 202.202.203.1 255.255.255.255

IP-address 192.168.3.254 192.168.2.254 *202.202.203.22 192.168.1.254 127.0.0.1

IP-address 192.168.3.254 192.168.2.254 *192.168.1.254 202.202.203.16 127.0.0.1