Thomson Gateways and Multiple IP Addresses

Thomson Gateways and Multiple IP Addresses

Date: June 2008

Version: 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.

Applicability: Thomson Gateway DSL Gateways and Routers R6.2.x

Updates: 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

http://www.thomson-broadband.com

http://www.thomson-broadband.com

i

Contents

1 Introduction.................................................................................. 4

2 Static Subnet with Numbered WAN Link ................................. 6

2.1 Scenario Overview .......................................................................................... 6

2.2 Practical Realisation ....................................................................................... 8

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

3.1 Scenario Overview ........................................................................................ 11

3.2 Practical Realisation ..................................................................................... 13

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



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



6 Multi-NAT................................................................................... 27



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



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



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

9.1 Scenario overview......................................................................................... 40

E-DOC-CTC-20051017-0157 v2.0

Contents


E-DOC-CTC-20051017-0157 v2.0 ii

iii

Contents

E-DOC-CTC-20051017-0157 v2.0

Chapter 1

1 Introduction

Purpose of this Application NoteThis 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 OverviewA 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 4

5

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

2 Static Subnet with Numbered WAN Link

IntroductionThis 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 Scenario Overview

ConceptIn 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).

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.

Route IP

1 PVC

GWBAS

Internet

Proxy

My Public Subnet

Web

Mail

MyIP2

MyIP1MyIP4

MyIP3

NOC

IP addresses used for thesenetworks can be private.

E-DOC-CTC-20051017-0157 v2.0 6

7

Chapter 2

ScenarioThe 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:

Figure 2 Scenario example of subnet with routing IP

The following sections will describe all the configuration steps needed:

To... See page...

Create the Uplink Interface 8

Define the Local Public Subnet 9

Define the Routing towards the Internet 9

Enable DNS Forwarding 9

Set the Correct Firewall Level 10

172.16.5.57

PVC: 8/35

GWDefault Route > 202.202.202.1

BASRoute: 202.202.203.16/29 > 172.16.5.57

InternetMy Public Subnet202.202.203.16/29

202.202.203.22

202.202.203.17

202.202.203.18

202.202.203.19

E-DOC-CTC-20051017-0157 v2.0

Chapter 2

2.2 Practical Realisation

Create the Uplink InterfaceFirst 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.

Proceed as follows:

1 Create an ATM interface.

Execute the following CLI commands to create ATM interface atm_MyIPoA:

2 Create an IP interface.

Execute the following CLI commands to create IP interface ip_MyIPoA and to assign an IP address to it:

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:

4 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:

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.

:atm phonebook add name=phone_MyIPoA addr=8.35:atm ifadd intf=atm_MyIPoA:atm ifconfig intf=atm_MyIPoA dest=phone_MyIPoA encaps=llc ulp=ip:atm ifattach intf=atm_MyIPoA

:ip ifadd intf=ip_MyIPoA dest=atm_MyIPoA:ip ipadd intf=ip_MyIPoA addr=172.16.5.57 pointopoint=202.202.202.1

:ip ifattach intf=ip_MyIPoA

=>: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 8

9

Chapter 2

Define the Local Public SubnetAll 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:

Define the Routing towards the InternetNow 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:

Enable DNS ForwardingOptionally, 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:

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

:ip rtadd dst=0.0.0.0/0 gateway=202.202.202.1

: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 LevelIn 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:

If your 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. 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.

=>:firewall level list

Level Config============Active Level: Disabled

...=>

:firewall level set name=Disabled

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

11

Chapter 3

3 Static Subnet with Unnumbered WAN Link

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


ConceptIn this scenario the ISP provides the following configuration parameters:

The ATM connection parameters (VPI/VCI, encapsulation type, connection type IPoA),


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.

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.

No IP

1 PVC

GWBAS

Internet

Proxy

My Public Subnet

Web

Mail

MyIP2

MyIP1MyIP4

MyIP3

E-DOC-CTC-20051017-0157 v2.0

Chapter 3


Figure 4 Scenario example of unnumbered WAN interface

The following sections describe all the configuration steps needed:

To... See page...



Define the Routing towards the Internet 14

Set the Default IP Address 14

Enable DNS Forwarding 15


No IP

PVC: 8/35

GWDefault Route > IP_MyIPoA

BAS202.202.202.1Route: 202.202.203.16/29 > IPoA...


202.202.203.22

202.202.203.17

202.202.203.18

202.202.203.19

E-DOC-CTC-20051017-0157 v2.0 12

13

Chapter 3


Create the Uplink InterfaceFirst 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.

Proceed as follows to create the IPoA uplink interface:


Execute the following CLI commands to create ATM interface atm_MyIPoA:


Execute the following CLI commands to create IP interface ip_MyIPoA:

3 Enable the IP interface.

Execute the following CLI command to enable IP interface ip_MyIPoA:


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:

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.

:atm phonebook add name=phone_MyIPoA addr=8.35:atm ifadd intf=atm_MyIPoA:atm ifconfig intf=atm_MyIPoA dest=phone_MyIPoA encaps=llc ulp=ip:atm ifattach intf=atm_MyIPoA

:ip ifadd intf=ip_MyIPoA dest=atm_MyIPoA

No IP address is assigned to this IP interface.

:ip ifattach intf=ip_MyIPoA

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

E-DOC-CTC-20051017-0157 v2.0

Chapter 3

Define the Routing towards the InternetAs 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:

Set the Default IP AddressWhen 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:

Execute the following CLI command to verify the default IP addresses of the Thomson Gateway IP interfaces:

Execute the following CLI command to verify the default IP interface of the Thomson Gateway:

:ip rtadd dst=0.0.0.0/0 intf=My_IPoA

:ip ipconfig addr=202.202.203.22 primary=enabled:ip ifconfig intf=lan1 primary=enabled

=>:ip iplist Interface Type IP-address Point-to-point/Mask5 guest1 Ethernet *192.168.3.254 255.255.255.04 dmz1 Ethernet *192.168.2.254 255.255.255.03 lan1 Ethernet *202.202.203.22 255.255.255.2483 lan1 Ethernet 192.168.1.254 255.255.255.00 loop Internal 127.0.0.1 255.255.255.255=>

The IP-address preceded by an asterisk (*) is the primary address of an interface.

=>:ip iflist expand=enabledInterface 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

15

Chapter 3

Enable DNS ForwardingOptionally, 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:



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.

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



...=>


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

Chapter 4

4 Static Subnet in Full Unnumbered mode

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


ConceptIn this scenario the ISP provides the following configuration parameters:

The ATM connection parameters (VPI/VCI, encapsulation type, connection type PPP),


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.

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.

No IP

1 PVC

GWBAS

Internet

Proxy

My Public Subnet

Web

Mail

MyIP3

No IPProxy-ARP forGatway IP@

MyIP1

MyIP2

E-DOC-CTC-20051017-0157 v2.0 16

17

Chapter 4


Figure 6 Scenario example of full unnumbered mode

The following sections will describe all configuration steps needed:

The special part of this configuration is the default gateway’s 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.

To... See page...



Proxy ARP for the Gateway 19

Check Connectivity 19


No IP

PVC: 8/35

GWDefault Route > IP_MyPPP

BAS202.202.203.1Route: 202.202.203.16/29 > PPP...


No IPProxy-ARP for202.202.203.1

202.202.203.17/24Gateway: 202.202.203.1

202.202.203.18/24Gateway: 202.202.203.1

202.202.203.19/24Gateway: 202.202.203.1

E-DOC-CTC-20051017-0157 v2.0

Chapter 4


Create the Uplink InterfaceThe 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:


Execute the following CLI commands to create ATM interface atm_MyPPP:

2 Create a PPP interface.

Execute the following CLI commands to create PPP interface ppp_MyPPP:

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:

4 Connect the PPP interface.

Execute the following CLI commands to connect the PPP interface:

:atm phonebook add name=phone_MyPPP addr=8.35:atm ifadd intf=atm_MyPPP:atm ifconfig intf=atm_MyPPP dest=phone_MyPPP encaps=vcmux ulp=ppp:atm ifattach intf=atm_MyPPP

For IPoA, the corresponding commands are the same, but the ulp parameter is ‘ulp=ip’

:ppp ifadd intf=ppp_MyPPP:ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword unnumbered=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.

:ppp rtadd intf=ppp_MyPPP dst=0.0.0.0/0

For IPoA the corresponding command would be ‘:ip rtadd’

:ppp ifattach intf=ppp_MyPPP

E-DOC-CTC-20051017-0157 v2.0 18

19

Chapter 4


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:

Proxy ARP for the GatewayAll 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:

2 Check the result.

Execute the following CLI commands to verify whether the proxy-ARP entry has been added:

Check ConnectivityFrom 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).

:ip rtadd dst=202.202.203.16/29 intf=lan1

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

=>:ip arplistInterface IP-address HW-address Type2 lan1 202.202.203.1 00:0e:50:34:00:f2 PROXY...=>

E-DOC-CTC-20051017-0157 v2.0

Chapter 4


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.



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.



...=>



E-DOC-CTC-20051017-0157 v2.0 20

21

Chapter 5

5 Subnet with IPCP Subnet Mask Option

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


ConceptIn 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:

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.

Calculates subnet (1 > n) > Uses MyIP1 for itself > Populates DHCP server with MyIP2 > MyIPn

1 PVC

GWBAS

Internet

Proxy

My Public Subnet

PPP ‘server’Offers IPCP subnetmask

Web

Mail

DHCPserver

E-DOC-CTC-20051017-0157 v2.0

Chapter 5


Figure 8 Scenario example of subnet with IPCP subnet mask option


To... See page...

Configure the DHCP Server 23



Verify the Connection 26

IP@: 202.202.203.16Mask: 29Gateway: 202.202.202.1

IPCP Offer

PVC: 8/35

GW202.202.203.16Default Route > PPP intf

BAS202.202.202.1Route: 202.202.203.1.16/29 > PPP

Internet

202.202203.19

My Public Subnet202.202.203.16/29

202.202.203.17

202.202.203.18

DHCPserver

202.202.203.17202.202.203.18...202.202.203.22

E-DOC-CTC-20051017-0157 v2.0 22

23

Chapter 5


Configure the DHCP ServerProceed 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:

2 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:

3 Make sure the DHCP server is running.

Execute the following CLI command to check the status of the DHCP server:

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

:dhcp server pool add name=IPCP_pool index=0:dhcp server pool config name=IPCP_pool leasetime=60 unnumbered=enabled

:dhcp server pool config name=LAN_private leasetime=60

=>:dhcp server configState: enabled

:dhcp server config state enabled

E-DOC-CTC-20051017-0157 v2.0

Chapter 5

Create the Uplink InterfaceCreate 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:




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:

3 Enable IPCP subnet masking.

Execute the following CLI commands to set all necessary parameters of the PPP interface to activate IPCP subnet masking:

4 Enable the PPP interface.

Execute the following CLI command to enable 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.

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


E-DOC-CTC-20051017-0157 v2.0 24

25

Chapter 5





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.



...=>



E-DOC-CTC-20051017-0157 v2.0

Chapter 5

Verify the ConnectionProceed as follows to see if the connection is working correctly:

1 Execute the following CLI command to check the status of the PPP interface:

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:

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:

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.

=>: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 = =>

=>:ip iplist Interface Type IP-address Point-to-point/Mask5 guest1 Ethernet *192.168.3.254 255.255.255.04 dmz1 Ethernet *192.168.2.254 255.255.255.02 lan1 Ethernet *192.168.1.254 255.255.255.01 ppp_MyPPP Serial 202.202.203.16 202.202.203.10 loop Internal 127.0.0.1 255.255.255.255=>

=>:dhcp server pool list name=IPCP_poolPool Start End Intf State0 IPCP_pool 202.202.203.17 202.202.203.22 lan1 UP

DHCP server = 192.168.1.254 [unnumbered]Netmask = 255.255.255.248Leasetime = 60Gateway = 202.202.203.1DNS domain = lanDNS metric = 0

DNS address list:192.168.1.254 (local DNS)202.204.254.20=>

E-DOC-CTC-20051017-0157 v2.0 26

27

Chapter 6

6 Multi-NAT

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


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

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.

NAT configuration:PubIP_X > PubIP_Y are available forPrivateIP_A > PrivateIP_ZFirst come, first served

1 PVC

GWBAS

Internet Private subnet

PrivateIP_C

PrivateIP_B

PrivateIP_A

2 public IP addresses > PubIP_X > PubIP_Y

E-DOC-CTC-20051017-0157 v2.0

Chapter 6


Figure 10 Scenario example of M-N NAT


To... See page...


Define M-N NAT 30


NAT configuration:202.202.203.[16..17] available for192.168.1.[1..253]

PVC: 8/35

GW202.202.203.16202.202.203.17

BAS202.202.203.1

Internet

192.168.1.3

192.168.1.2

192.168.1.1

My Private Subnet192.168.1.1/24

E-DOC-CTC-20051017-0157 v2.0 28

29

Chapter 6


Create the Uplink InterfaceFirst 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.

Proceed as follows:


Execute the following CLI commands to create ATM interface atm_MyETHoA:

2 Create an Ethernet interface.

Execute the following CLI commands to create Ethernet interface eth_MyETHoA:


Execute the following CLI commands to create IP interface IP_MyETHoA and assign the two public IP addresses to it:

4 Create a route to the Internet.

Execute the following CLI commands to inject a default route into the routing table:

Using any other type of statically configured uplink interface does not impact the other steps to be done during the configuration.

:atm phonebook add name=phone_MyETHoA addr=8.35:atm ifadd intf=atm_MyETHoA:atm ifconfig intf=atm_MyETHoA dest=phone_MyETHoA encaps=llc ulp=mac:atm ifattach intf=atm_MyETHoA

:eth ifadd intf=eth_MyETHoA:eth ifconfig intf=eth_MyETHoA dest=atm_MyETHoA:eth ifattach intf=eth_MyETHoA

:ip ifadd intf=ip_MyETHoA dest=eth_MyETHoA:ip ipadd intf=ip_MyETHoA addr=202.202.203.16/24 addroute=enabled:ip ipadd intf=ip_MyETHoA addr=202.202.203.17/24 addroute=enabled:ip 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.


E-DOC-CTC-20051017-0157 v2.0

Chapter 6

Define M-N NATTo 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:

Execute the following CLI command to configure the M-N NAT that maps all internal addresses to the two public IP addresses:

Set the Correct Firewall LevelIn 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.


If your current level is not ‘Standard’ or any higher-security level, execute the following CLI command:

:nat ifconfig intf=ip_MyETHoA translation=enabled

:nat mapadd intf=ip_MyETHoA type=nat outside_addr=202.202.203.[16-17] 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.



...=>

:firewall level set name=Medium


E-DOC-CTC-20051017-0157 v2.0 30

31

Chapter 7

7 Transparent NAT

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


ConceptAs mentioned above, in the case of transparent NAT, no NAT is performed. This can be useful when NAT-unfriendly 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.


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.

NAT configuration:PubIP_[X..Y] should be forwardedtransparantly towards PubIP_[X..Y]

1 PVC

GWBAS


PrivateIP_C

PubIP_Y

PubIP_X

2 public IP addresses > PubIP_X > PubIP_Y

E-DOC-CTC-20051017-0157 v2.0

Chapter 7


Figure 12 Scenario example of transparent NAT


To... See page...


Define Transparent NAT 34


NAT configuration:202.202.203.[16..17] to be forwardedtransparantly to 202.202.203.[16..17]

PVC: 8/35

GW202.202.203.16202.202.203.17

BAS202.202.203.1

Internet

192.168.1.3

202.202.203.17

202.202.203.16

My Private Subnet192.168.1.1/24

E-DOC-CTC-20051017-0157 v2.0 32

33

Chapter 7


Create the Uplink InterfaceFirst 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.

Proceed as follows:


Execute the following CLI commands to create ATM interface atm_MyETHoA:

2 Create an Ethernet interface.

Execute the following CLI commands to create Ethernet interface eth_MyETHoA:


Execute the following CLI commands to create IP interface IP_MyETHoA and assign the two public IP addresses to it:

4 Create a route to the Internet.

Execute the following CLI commands to inject a default route into the routing table:

Using any other type of statically configured uplink interface does not impact the other steps during the configuration.

:atm phonebook add name=phone_MyETHoA addr=8.35:atm ifadd intf=atm_MyETHoA:atm ifconfig intf=atm_MyETHoA dest=phone_MyETHoA encaps=llc ulp=mac:atm ifattach intf=atm_MyETHoA

:eth ifadd intf=eth_MyETHoA:eth ifconfig intf=eth_MyETHoA dest=atm_MyETHoA:eth ifattach intf=eth_MyETHoA

:ip ifadd intf=ip_MyETHoA dest=eth_MyETHoA:ip ipadd intf=ip_MyETHoA addr=202.202.203.16/24 addroute=enabled:ip ipadd intf=ip_MyETHoA addr=202.202.203.17/24 addroute=enabled:ip 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.


E-DOC-CTC-20051017-0157 v2.0

Chapter 7

Define Transparent NATIn 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:

2 Define the Transparent NAT entry.

Execute the following CLI command to enable transparent NAT on our IPoEoA interface for both public IP addresses:

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:

4 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:

:nat ifconfig intf=ip_MyETHoA translation=enabled

:nat mapadd intf=ip_MyETHoA type=nat outside_addr=202.202.203.[16-17] 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.

:ip rtadd dst=202.202.203.16/32 intf=lan1:ip rtadd dst=202.202.203.17/32 intf=lan1

:ip arpadd intf=lan1 ip=202.202.203.1 hwaddr=$_MACADDR

E-DOC-CTC-20051017-0157 v2.0 34

35

Chapter 7


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.



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.



...=>



E-DOC-CTC-20051017-0157 v2.0

Chapter 8

8 X+n NAT

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


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


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.

Receives only 1 address but knowsby configuration that it can use arange.

1 PVC

GWRoute: Default > interface to BRAS

BASRoute: IP[x..x+n] > interface to GW

Internet

PrivateIP_C

PrivateIP_B

PrivateIP_A

Private Subnet

BAS offers 1 address (IPx) butassigns a range in its routing table.

E-DOC-CTC-20051017-0157 v2.0 36

37

Chapter 8


Figure 14 Scenario example of X+n NAT

In this scenario we will make use of N-N NAT.


To... See page...


Define X+n NAT 38


IP@: 202.202.203.16Gateway: 202.202.202.1...

Offer

PVC: 8/35

GW202.202.203.16Default Route > PPP intf

BASRoute: 202.202.203.[16..22] > PPP

Internet

192.168.1.3

192.168.1.2

192.168.1.1

Private Subnet

202.202.203.[16..22]>>192.168.1.[1..7]

N-N NAT

E-DOC-CTC-20051017-0157 v2.0

Chapter 8


Create the Uplink InterfaceCreate 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.


Proceed as follows:





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:

Define X+n NATThe 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:

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.


:ppp ifadd intf=ppp_MyPPP:ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword


: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

39

Chapter 8

Set the Correct Firewall LevelIn 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’.


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.

Enable the Dynamic ConnectionNow 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:



...=>




E-DOC-CTC-20051017-0157 v2.0

Chapter 9

9 Public IP address Distribution by Hyper-NAT

IntroductionThe 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 Scenario overview

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


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.

NAT configuration:PubIP_X: Basic NAPT for LAN PCsPubIP_Y: N-N NAT for Web in LAN >> IP@ of server can stay as beforePubIP_Z: Transparent NAT for IPSec GW >>Public IP@ for VPN GW at public side to avoid NAT issues

Any link type,static configuration

1 PVC

GWBAS


IPSEC GW

Webserver

PCs

E-DOC-CTC-20051017-0157 v2.0 40

41

Chapter 9


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.


To... See page...


Define NAT Entries 43


NAT configuration:202.202.203.16 > NAPT for local PCs202.202.203.17 > 192.168.1.200 (Webserver)202.202.203.18 > 202.202.203.18 (IPSEC GW)

PVC: 8/35

GWBAS202.202.203.16/29 > PPP link


IPSEC GW202.202.203.18192.168.1.210

Webserver192.168.1.200

PCs192.168.1.x

E-DOC-CTC-20051017-0157 v2.0

Chapter 9


Create the Uplink InterfaceCreate 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).


Proceed as follows:





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:

4 Connect the PPP interface.

Execute the following CLI command to enable the PPP interface:


:ppp ifadd intf=ppp_MyPPP:ppp ifconfig intf=ppp_MyPPP dest=atm_MyPPP user=MyUsername password=MyPassword unnumbered=enabled

The values ‘MyUsername’ and ‘MyPassword’ are to be replaced by the actual PPP connection credentials that are offered by your ISP



E-DOC-CTC-20051017-0157 v2.0 42

43

Chapter 9

Define NAT EntriesProceed 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:

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:

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

Execute the following CLI command to create the transparent NAT entry:

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:

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:

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

:nat mapadd intf=ppp_MyPPP type=nat outside_addr=202.202.203.17 inside_addr=192.168.1.200

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.

:nat mapadd intf=ppp_MyPPP type=napt outside_addr=202.202.203.18 inside_addr=202.202.203.18

:ip rtadd dst=202.202.203.18/32 intf=lan1

:ip arpadd intf=lan1 ip=202.202.203.1 hwaddr=00-0E-50-34-00-F2

E-DOC-CTC-20051017-0157 v2.0

Chapter 9




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.

Verify the ConnectionProceed as follows to see if the connection is working:

1 Execute the following CLI command to check the status of the PPP interface:

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



...



=>: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 =

E-DOC-CTC-20051017-0157 v2.0 44

45

Chapter 9

2 Execute the following CLI command to verify the NAT mappings:

=>:nat maplist expand=enabledIdx Type Interface Outside Address Inside Address Use... 5 NAT ppp_MyPPP 202.202.204.11 202.202.204.11 0 Access List............... 202.202.204.11 Foreign Address........... any Protocol.................. any Flags..................... Static Description............... Transparent Two-way NAT Creator Data.............. 0 6 NAT ppp_MyPPP 202.202.204.10 192.168.1.200 0 Access List............... 192.168.1.200 Foreign Address........... any Protocol.................. any Flags..................... Static Description............... Two-way NAT Creator Data.............. 0 7 NAPT ppp_MyPPP 202.202.204.9 unmapped 0 Access List............... any Foreign Address........... any Protocol.................. any Flags..................... Static Description............... Outbound NAPT without defserver Creator Data.............. 0

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.

http:\\www.thomson-broadband.com

Documents

Thomson Gateways and Multiple IP Addresses