3.10.20.19 Release notes:

 

New Features:

  
  This section contains a list of new features implemented in this release from
  the last public release of 3.10.12.3

  1. FTP throttling
  2. FTP WAN Access
  3. One-to-One NAPT support
  4. IPSec Client ID field for main mode.
 

Resolved Issues:

  
  This section contains issues resolved in this release.
  
  Networking
    1. Ethernet header fix. This could cause the USR8200 to lock up. This was
       most commonly seen while handling PPTP traffic but could also happen in
       normal traffic.
  
  IPSec
    1. Firewall related issues.
    2. Traffic stops within 10 - 180 seconds (RIP related; see RIP).
    3. When rebooting while a hard drive is connected, IPSec reports "resolving host name"
       (timing issue on boot up).
    4. Due to Intel CSR 1.4 malfunction, IPSec connection is being blocked after
       massive traffic is transfered through the IPSec tunnel.
  
  PPTP
    1. Traffic stops within 10 - 180 seconds (RIP related; see RIP).
    2. Multiple connections from behind the same gateway would fail.
    3. With multiple LANs configured you could not change the PPTP
       DHCP pool over to a secondary LAN on the USR8200.
    4. Throughput through the USR8200s PPTP Client was slow.
  
  RIP
    1. During RIP updates every 180 seconds the router randomly deleted route
       entries RIP never created. This had a side effect for some VPN sessions
       where traffic would stop flowing.
  
  DNS
    1. UDP checksum field in the DNS query is set to 0, which started causing
       problems when Comcast changed from ATTBI DNS servers to their own. The
       proper fix should be done on Comcasts network.
  
  Firewall
    1. When in Maximum security level, defining a bridge over USR8200's LAN
       devices and then removing it, renders the board inaccessible.
    2. There is no way to connect more than one SIP client that uses an external
       SIP proxy to the USR8200.
    3. Error messages appear in the USR8200 console (USR8200 CLI) when URL keyword
       filter is enabled. There seems to be no effect on functionality.
    4. Using MSN-Messenger Remote-Administration feature fails on some cases.
    5. If a SIP client in the LAN fails to register itself in the SIP parent
       registrar in 2 minutes, it will not be able to receive incoming calls.
    6. Some videos were having a problem playing on video.msn.com and
       movies.go.com.
  
  Bridge
    1. Disabling manually configured WAN-LAN bridge may cause the board to panic
       and reboot.
  
  CLI
    1. When assigning an IP address (that was used for one of the LAN devices) to
       a LAN bridge, USR8200 might crash.
  
  DDNS
    1. Entering invalid details to DNS Dynamic account disables update functionality.
  
  Printer
    1. The "Jobs Printed" counter is always "0" in the print server status page.
  
  PPP
    1. The override subnet mask field does not affect the route table.
    2. PPP will fail to detect one-byte protocol.
  
  Remote Update
    1. Remote update should wait 5 minutes after boot before attempting upgrade.
  
  UPnP
    1. When UPnP is enabled, both MSN and Windows Messengers in the LAN can fail
       to communicate with other Messengers in the Internet.
    2. Video conference, initiated with MSN Messenger 6.2 client in the WAN with
       MSN Messenger 6.2 client in USR8200's LAN may disconnect after a few minutes.
    3. When a video and an audio session are established between the Windows
       Messenger 4.2 clients both in the WAN and in USR8200's LAN, initiating an
       application sharing from WAN client may fail.
  
  Web-based Management
    1. When defining a static IP, a wrong error message appears.
    2. USR8200 crashes after entering SMTP authentication user name and password
       in the 'System settings' and pressing on 'Apply' twice.
    3. Firmware upgrade is stopped if the web-based management session is
       terminated.
    4. Invalid character in number fields "`" would be interpreted as "9".
 

Known Issues:

    
  This section contains a list of known issues with workarounds that are currently
  available.
    
  1. Changing from a static IP (Use the Following IP Address) to Dynamic IP
     (Obtain an IP Address Automatically), "Override Subnet Mask" is checked
     and contains a value that will error out unless you put in a correct
     Subnet Mask value or uncheck the box.
     Workaround: uncheck the Override Subnet Mask selection.
  2. SurfControl, if the USR8200 is set for a static IP Address the SurfControl
     module does not start on a reboot.
     Workaround: disable and re-enable SurfControl.

 

Reported Issues:

  This section contains a list of issues that have been reported and are either
  not considered issues based on design, can not be verified, have no workaround
  as of yet, or are still under investigation.
  
  1. Unable to set the subnet mask to 0.0.0.0 for a route being added manually.
  2. Unable to assign multiple networks to be routed through an IPSec connection.
  3. Hard Disk either gets marked as read only or delete access is removed. This
     is most typically caused by heavy fragmentation, disks exceeding the
     amount of times it is allowed to mount before a check disk is required to be
     performed, or a hard disk that goes to sleep and takes a while to wake up.
  4. Various hard-disk related issues with performance.
  5. No IP for NAT e-mail messages.
  6. Please visit the USR8200 support pages for an FAQ concerning
     Poor Network Performance.
 

How do I configure One-to-One NAPT:


What is One-to-One NAPT?

One-to-One NAPT is the ability to have ports translated from multiple IP addresses
defined on the WAN side of the USR8200 to different machines behind the USR8200 NAT (NAPT).

Diagram:
                  _______
                  | ISP |
                  -------
                _____|_____ 
                | USR8200 |
                -----------
   __________________|__________________
___|___  ___|___  ___|___  ___|___  ___|___  
| S1  |  | S2  |  | S3  |  | S4  |  | S5  |  
-------  -------  -------  -------  -------  
  FTP     HTTP      FTP     HTTP      FTP
 1.253    1.252    1.251    1.250    1.249

Your ISP has assigned you on network 120 of subnet 248, available IPs to use
123.123.123.(121 - 126)

Configuration of One-to-One NAPT using the diagram above:

 1. Login to the USR8200
 2. Click on Network Connections
 3. Click on the Edit icon for you WAN connection type (e.g. WAN Ethernet)
 4. Click on the Settings button
 5. At the very bottom you will see New IP Address for Additional IP Addresses;
    click on New IP Address
 6. Fill in the Static IP information.
  a. IP Address: This is an additional static IP address you own or are leasing
     from your Internet Service Provider. (e.g. 123.123.123.122)
  b. Subnet Mask: This is the Subnet in which your IP address falls into.
     (e.g. 255.255.248.0)
  c. Click on OK
 7. Repeat steps 5 and 6 for the additional IP addresses that are available within
    network 120 for subnet 248 to the USR8200 WAN interface if you plan on using all
    of them in this manner.
 8. Go to the Security page
 9. Click on the Advanced Filtering tab.
10. Under the "Input Rule Sets", Click on Initial Rules
11. Click on New Entry.
12. Fill in the necessary data for the WAN IP that you want redirected to the
    LAN Server.
  a. Source IP Address: This is only used if you want to make the connection
     to the server more secure, by only allowing one person to it, or more by
     duplicating this rule with other IPs that you want to allow to the server
     in this field.
  b. Destination IP Address: This is where the WAN IP address you want to redirect
     to the LAN Server. (e.g. 123.123.123.122)
  c. Check the redirect radio selection and fill in the LAN IP Address for the
     Server. (e.g. 192.168.1.253)
  d. Choose the services (ports) you wish to redirect to this Server.
     (e.g. FTP port Any - 21)
  e. Click on OK when you are finished.
13. Repeat steps 11 and 12 to configure additional One-to-One NAPT
    configurations.

After this procedure is completed, the servers that reside behind the USR8200
will only receive traffic for the services listed in the new rule sets.