List of pci compliant routers: What are the PCI DSS Firewall and Router Configuration Requirements

What are the PCI DSS Firewall and Router Configuration Requirements

What are the PCI DSS Firewall and Router Configuration Requirements?

It is essential to design and maintain a secure network infrastructure where cardholder data can be processed and stored. PCI DSS requirements include the configuration of routers and firewalls used to protect the CDE.

See Also: What are the Firewall Requirements for PCI DSS?

Set up firewall and router configurations to protect Cardholder Data Environments as follows:

All changes to firewall or network configurations should be formally documented and retained for future review.
For each CDE, there must be a network diagram documenting the systems and devices connected to that network.
A data flow diagram showing the movement of all cardholder data between systems and networks should be created.
You should update the network diagram and data flow diagrams based on changes in systems or processes.
Firewalls must exist at the CDE boundaries and between the DMZ and untrusted networks (i.e., non-CDE networks).
You should document groups, roles, and responsibilities for managing network components.
Firewalls must be configured to block access to all systems and system ports, except those defined in data flow diagrams.
You must document the reasons for each exception.
Rulesets for firewalls and routers should be reviewed at least every six months.
You should document review reports.
Examine and document firewall and router configurations and make sure of the following:
Verify that the configurations define the inbound and outbound traffic required for the cardholder data environment.
Verify that configurations are protected from unauthorized access.
Verify that working and stored configurations are synchronized.
Verify that perimeter firewalls are installed between all wireless networks and the cardholder data environment.

Examine firewall and router configurations to ensure there is no direct access between the Internet and system components in cardholder data environments and do the following:

A DMZ must be implemented to restrict incoming traffic only to system components that provide authorized public services, protocols, and ports.
Verify that incoming Internet traffic is limited to IP addresses within the DMZ.
Verify that anti-fraud measures are in place, e.g., internal addresses cannot pass from the Internet to the DMZ.
Verify that traffic from the cardholder data environment to the Internet is explicitly prohibited.
Verify that firewalls only allow connections to CDE.
Verify that cardholder data is not stored inside the DMZ (outside of the CDE).
Verify that private IP addresses and routing information are not accessible to unauthorized persons.
Install the personal firewall software on all portable devices used to access the CDE that connects to the Internet while outside the network.
End users should not be able to change the firewall’s configuration.
Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

As a general rule, each PCI Standard should be reviewed annually and updated as needed to reflect changes in business objectives or the risk environment.

How Should Firewalls Be Located and Configured?

Firewalls are devices or programs that control network traffic flow between networks or hosts that use different security postures. Although firewalls are commonly addressed in relation to Internet access, they can also be used in other forms of networks.

For example, many corporate networks use firewalls to restrict connectivity to and from internal networks to serve more sensitive functions such as accounting or reporting. An organization can block unauthorized access to its systems and resources by using firewalls to control these areas’ connectivity.

The installation of a firewall that is sufficient for your environment adds an extra layer of protection. Firewalls are commonly used by companies to fulfill mandated security standards such as FISMA or PCI DSS.

See Also: Firewall Rule Configuration Best Practices For PCI Compliance

Payment Card Industry (PCI) Data Security Standard requirement one specifically requires a firewall. Several types of firewall technologies are available. One way to compare its capabilities is to look at the Transmission Control Protocol / Internet Protocol (TCP/IP) layers that each can examine.

TCP / IP communications consist of four layers that work together to transfer data between hosts. Data is transferred from the highest layer to the lowest layer when a user wants to migrate data between networks, and each layer adds more information.

The lowest layer sends the collected data over the physical network, and the data is then transmitted from the layers upwards to its destination. Simply put, the data generated by one layer is encapsulated in a larger container by the underlying layer.

Addresses in the data link layer assigned to network interfaces are called media access control (MAC) addresses. As an example, we can give an Ethernet address that belongs to an Ethernet card. Firewall policies rarely deal with the data link layer. Addresses on the network layer are called IP addresses.

In comparison to network addresses, the transport layer defines unique network applications and communication sessions. A host can have any number of transport-layer sessions with other hosts on the same network.

The transport layer can also include the concept of anchor points. A destination port number generally identifies a service that is listening on the destination host, while a source port number typically identifies the source host port number to which the destination host can respond.

Some transport protocols, such as TCP and UDP, have ports, while others don’t. Combining the source IP address and port with the destination IP address and port helps identify the session. The highest tier represents end-user applications. Firewalls can examine application traffic and use it as the basis for policy decisions.

Basic firewalls run on one or more layers, while more advanced firewalls examine all layers. People who examine more layers can make more detailed and comprehensive examinations.

Advanced applications and protocols can theoretically be accommodated by firewalls that recognize the application layer, and user-oriented services can be provided. For example, a firewall that only processes lower layers cannot usually identify specific users. However, a firewall with application-layer capabilities can apply user authentication and log events to specific users.

NAT can be thought of as a form of routing rather than a firewall.
Organizations must allow outbound traffic using only source IP addresses used by the organization.
A compliance check is useful in a firewall only when it can block communication that could harm protected systems.
It’s crucial to determine if the firewall can serve as an application proxy when selecting the type of firewall to deploy.
The management of personal firewalls should be centralized to efficiently create, deploy and enforce policies for all users and groups.

Firewalls are used to separate networks with different security requirements, such as the Internet and internal network hosting servers with sensitive data. Organizations should use firewalls where their internal networks and systems interface with external networks and systems and where security requirements differ between internal networks.

Below we will examine where organizations’ firewalls should be placed and where other networks and systems should be located in relation to their firewalls.

Since one of the firewall’s primary roles is to prevent unauthorized traffic from entering and, in certain instances, exiting a network, it should be positioned at the edge of logical network boundaries.

Firewalls are usually installed as a node where the network is divided into several paths or inline along a single route. In routed networks, the firewall is usually located on the network at a location just before the traffic enters the router (entry point) and is sometimes located in the same location as the router.

For a multipath node, it is rare to place the firewall after the router because the firewall device must follow each of the multiple egress paths that are typically present in such cases.

The vast majority of hardware firewall devices include routing capabilities. In switched networks, a firewall is usually part of the switch itself to allow the switch to protect as many segments as possible.

A firewall receives unchecked traffic, controls it according to the firewall’s policy, and then acts appropriately, passing or blocking the traffic. Since all traffic on a network has one direction, policies are based on the traffic moves’ direction.

Some firewalls control traffic in both directions. For example, if they are set up to prevent certain traffic from an organization’s local area network (LAN) from escaping to the Internet, they control traffic in both directions. The protected side of the firewall is the side facing the outside network in these situations.

Generally, a firewall should conform to the layout of an existing network. However, an organization can change its network architecture while deploying a firewall as part of an overall security upgrade.
Different common network architectures lead to different options for where to place a firewall, so an organization should consider which architecture works best for security objectives.
If an edge firewall has a DMZ, consider which outward facing services from the DMZ should be run and remain on the internal network.
Do not rely on NATs to take advantage of firewalls.
Putting one firewall behind another will accomplish the desired security target in certain cases, but having several layers of firewalls can be cumbersome.

Based on the organization’s information security policies, a firewall policy specifies how firewalls can handle network traffic for various IP addresses and address ranges, protocols, applications, and content types.

Before a firewall policy can be established, some form of risk analysis should be performed to develop a list of traffic types the organization needs and to classify how they should be secured. The risk analysis should include what types of traffic under which conditions may pass through a firewall.

This risk analysis should be based on the evaluation of threats. Security vulnerabilities; the measures are taken to reduce security vulnerabilities, and the effects that will occur if systems or data are compromised should be identified.

The firewall policy should be documented in the system security plan and should be maintained and updated frequently as new classes of attacks or vulnerabilities emerge, or the organization’s needs for networking applications change. The policy should also provide detailed guidelines on how to comply with rule changes.

In general, firewalls can block both inbound and outbound traffic that isn’t expressly allowed by the firewall policy, i.e., traffic that the company doesn’t need. This practice, known as a denial by default, reduces the risk of attacks and reduces traffic volume carried on the organization’s networks.

Due to hosts’ dynamic nature, networks, protocols, and applications, denying by default is a more secure approach than allowing all traffic that is not explicitly prohibited.

The firewall strategy of a company should be based on a rigorous risk analysis.
Both inbound and outbound traffic should be blocked by firewall rules, with exceptions for requested traffic.
In addition to content, policies should consider the traffic’s source and destination.
Many types of IPv4 traffic, such as invalid or private addresses, should be blocked by default.
Organizations must have policies to handle inbound and outbound IPv6 traffic.
An organization should determine which applications can send traffic to or from its network and establish firewall policies to block traffic for other applications.

PCI DSS Firewall Configuration Tips

Your firewall is an essential part of your network security because it is the first line of protection against online attackers. Configuring a firewall can be a challenging task, but breaking it down into smaller tasks can make it much easier to handle.

See Also: Firewall Security Controls Checklist

The steps required for PCI DSS and involved in firewall configuration are outlined in the following guide. Many suitable firewall models can be used to protect your network. The following steps are important regardless of the firewall model you choose.

Ensure the security of your firewall

Your network security is “game over” if an intruder gains administrative access to your firewall. As a consequence, protecting your firewall is the first and most important step in this process. Never deploy a firewall that isn’t properly protected, at the very least with the following configuration actions:

Update your firewall to the latest firmware.
Delete, disable or rename default user accounts and change all default passwords.
Be sure to use only complex and secure passwords.
If more than one administrator will manage the firewall, create additional administrator accounts with limited privileges depending on responsibilities.
Never use a user account that has been shared.
Disable the simple network management protocol (SNMP) or configure the community string to be secure.

Design your firewall zones and IP addresses

To secure your network’s valuable properties, you must first find out what they are. Then plan your network structure so these assets can be grouped and placed in networks (or zones) based on similar sensitivity level and functionality.

For example, all of your servers that provide Internet services must be located in a special zone that allows only minimal inbound traffic from the Internet (this zone is often called the demilitarized zone or DMZ).

Internal server zones should be used for servers that should not be accessed directly from the Internet, such as database servers. Similarly, workstations, point-of-sale devices, and voice over Internet protocol (VOIP) systems can often be located in internal network regions.

The more zones you make, the more stable your network will be in general. Bear in mind, however, that handling more zones requires more time and money, so you should be vigilant when determining how many network zones to use.

Internal IP addresses must be used by all internal networks if you’re using IP version 4. Network address translation (NAT) must be configured to allow internal devices to communicate on the Internet as required.

You can start designing firewall zones and assigning them to your firewall interfaces or sub-interfaces once you’ve built your network zone structure and created the corresponding IP address scheme.

Configure access control lists

You must determine precisely what traffic should enter and exit each zone. This traffic will be allowed using firewall rules called access control lists (ACLs) that apply to each interface or sub-interface in the firewall.

Make your ACLs as specific as possible to the exact source or destination IP addresses and port numbers. To filter out all unapproved traffic, make sure each access control list has a “deny all” rule at the top. Apply inbound and outbound ACLs to each interface and sub-interface in your firewall to ensure that only permitted traffic enters and exits each sector.

It is generally recommended that your firewall management interfaces (including both secure shell (SSH) and web interfaces) be disabled from public access whenever possible. This will help protect your firewall configuration from outside threats. Be sure to disable all unencrypted protocols for firewall management, including Telnet and HTTP connections.

Configure your firewall services and logging

If your firewall can also act as a dynamic host configuration protocol (DHCP) server, network time protocol (NTP) server, or intrusion prevention system (IPS), configure the services you want to use. Disable any extra services you don’t want to use.

To meet the PCI DSS requirements, configure your firewall to report to your logging server and ensure that the logs have enough detail to meet the 10.2 to 10.3 PCI DSS requirements.

Test your firewall configuration

Verify that your firewall is functioning properly in a test setting. Remember to verify that your firewall is blocking traffic that should be blocked based on your ACL configurations. Vulnerability scanning and penetration testing can also be done on your firewall.

Always maintain a copy of your firewall settings in a secure location so that all of your hard work isn’t wasted if your hardware fails. Have your setup checked by a security professional to ensure that it is set up to keep your data as protected as possible.

Manage your firewall

Firewall logs should be monitored, firmware updated, vulnerability scans performed, and firewall rules reviewed at least every six months. Finally, make sure you document your process and are diligent in performing these ongoing tasks to ensure that your firewall continues to protect your network.

Latest posts

PCI Compliance with Meraki — Cisco Meraki

Last updated
Save as PDF

The PCI Standard

The Payment Card Industry Data Security Standard is a worldwide information security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC). The standard was created to help organizations that process card payments prevent credit card fraud through enhanced security measures. The standard applies to all organizations which hold, process, or pass cardholder information from any card branded with the logo of one of the card brands.

The PCI DSS v3.2 standard describes clear requirements for building compliant wireless LANs. Meraki’s secure wireless solutions offer a simple, cost-effective means of achieving PCI compliance. Meraki’s integrated mapping, logging, and rogue AP detection tools eliminate the need to build a solution from component parts. In addition, centralized control of geographically distributed networks makes it easy to implement the same PCI-compliant architecture across large numbers of retail locations.

Meraki is certified as a PCS DSS v3.2 Level 1 Service Provider (the most rigorous audit level). You can learn more about Meraki’s own PCI DSS compliance at https://meraki.cisco.com/trust#pci .

Network Segmentation and PCI Compliance

PCI audits can be expensive and time-consuming, especially when the audit scope includes your entire network infrastructure. PCI DSS security requirements apply to all system components, where “system components” are defined as “any network component, server, or application that possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access point, network appliances, and other security appliances.

Meraki’s cloud hosted WLAN controller is out of band, meaning that wireless traffic (including cardholder data) does not flow through Meraki’s cloud-hosted controller or any other Meraki infrastructure not behind your firewall. Meraki’s datacenters are SAS 70 type II certified, feature robust physical and cyber security protection, and are regularly audited by third parties. While Meraki’s datacenters are considered out of scope for any WLAN networks PCI audit, Meraki has taken the additional step to obtain PCI certification for our datacenters. Meraki datacenters have passed the Level 1 PCI audit, the most rigorous level for PCI compliance.

One way that the scope of a PCI audit can be reduced is through network segmentation. Network segmentation, or isolation of the cardholder data environment (CDE), from the remainder of the corporate network is not a PCI DSS requirement. However, it is recommended as a means of reducing the scope and cost of a PCI DSS assessment as well as a means of reducing general risk to the organization. If your wireless network is not being used to transmit sensitive cardholder data, then the wireless network can potentially be segmented from the CDE, removing the wireless network from the scope of a PCI audit. There are two ways to achieve this segmentation; locating the WLAN on a completely separate wired network infrastructure that is not connected to the CDE, and using firewall segmentation.

Wireless Network Not Connected to CDE

Segmentation can be achieved by locating the wireless network on a completely separate, parallel wired network that is not connected to the CDE at all. The access points cannot be connected to any switches, routers or other wired infrastructure that is connected even peripherally to the CDE. In addition, the wireless network must have its own Internet connection (ie. it cannot share a modem or firewall with the CDE network).

Firewall-Segmented Wireless Network Connected to CDE

If the wireless LAN is connected to the CDE, it can still be segmented from the CDE if it is separated from the CDE with a firewall according to the following PCI-DSS requirement:

1.2.3 Install perimeter firewalls between any wireless networks and the CDE, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the CDE.

Meraki’s built-in firewall (LAN Isolation) can be used to effectively deny any wireless traffic into the local LAN or CDE. To provide complete segmentation of the wireless LAN from the CDE, LAN isolation must be turned on for all SSIDs.

A simple flow chart documenting how a network administrator can ensure that their Meraki wireless network is compliant with these requirements is included in Appendix A. In addition, an example of how to configure a segmented network in Dashboard is included in Appendix B.

VLANs and Network Segmentation

Virtual local area networks (VLANs) cannot be relied upon for network segmentation (eg. having the CDE on one VLAN and the WLAN on separate VLANs) and will not necessarily take the wireless out of the PCI DSS scope. Hackers can potentially hop across VLANs using known techniques if adequate access controls between VLANs are not put in place.

PCI Compliance for a Non-Segmented Meraki Wireless LAN

The following table lists the PCI requirements that are applicable to wireless networks that are part of the CDE (ie. are not segmented from the CDE and/or are transmitting sensitive cardholder data) and how a Meraki wireless LAN can be used to satisfy each requirement:

PCI Requirement	Meraki Meets	How Meraki Helps
1.2.3 Install perimeter firewalls between any wireless networks and the CDE, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the CDE.	Yes	This requirement is considered a best practice even for non-segmented networks to limit traffic from the wireless network into the CDE to only that required for business purposes from authorized users and devices. Meraki’s built-in firewall (LAN Isolation) and Identity Policy Manager (IPM) can be used to effectively deny or control any wireless traffic into the local LAN or the Internet. LAN isolation should be used for guest SSIDs and IPM custom firewall rules should be used for other SSIDs to limit access to the LAN to business-necessary traffic only.
2.1.1 For wireless environments connected to the CDE or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission.	Yes	Meraki does not ship with default keys that need to be changed. Meraki supports the latest strong security standards and makes it easy to ensure they are setup correctly.
4.1.1 Ensure wireless networks transmitting cardholder data or connected to the CDE, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.	Yes	Meraki supports the strongest encryption standards, including WPA2-PSK, and WPA2-Enterprise (802.11i) with AES encryption.
6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release.	Yes	Meraki can automatically install the latest firmware on APs via the cloud.
7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to «deny all» unless specifically allowed.	Yes	Meraki provides full, readonly, and lobby ambassador roles. Access can be further restricted to a specific wireless network within an organization.
9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices.	Yes	Meraki enterprise access points feature have 3 different physical security mechanisms, including padlock and security screw, that restrict physical access. Meraki APs can also be placed in the plenum to make them more secure.
10.5.4 Write logs for externalfacing technologies onto a log server on the internal LAN…verify that logs for external-facing technologies are offloaded or copied onto a secure centralized internal log server media.	Yes	Meraki network logs are automatically stored in a centralized environment and backed up in geographically redundant data centers.
10. 6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers.	Yes	Meraki provides centralized monitoring and logging of all wireless access attempts in a detailed event log.
11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.	Yes	Meraki includes IDS, also known as rogue AP detection, which reduces the need for manual scans.
12.3 Develop usage policies for critical employee-facing technologies (for example, remote – access technologies, wireless technologies…) to define proper use of these technologies for all employees and contractors.	Yes	Implementer’s responsibility
12. 9.5 Include alerts from intrusion detection, intrusion-prevention, and file-integrity monitoring systems.	Yes	Meraki’s wireless intrusion detection system generates automatic alerts to warn of potential security threats.

A simple flow chart documenting how a network administrator can ensure that their Meraki wireless network is compliant with these requirements is included in Appendix A. In addition, an example configuration of a PCI-compliant network configuration for a Meraki network that is part of the CDE is contained in Appendix C.

Additional details on the PCI requirements can be found by downloading the standard here.

Meraki PCI Report Tool

An administrator can check network settings against PCI DSS v2.0 and 3.0 WLAN requirements using the PCI Report page under the Monitor tab in an MR access point network. The results will indicate a pass/fail for each WLAN PCI requirement, with details on why. In the case of a failure, guidance is provided on what network settings need to be changed to get into compliance. The report can be printed and filed away or given to a security auditor. PCI DSS version 3.1 and 3.2 included minor changes to the 3.0 standard.

PCI Compliance Documentation

For PCI DSS documentation such as System and Organization Controls (SOC2) or Attestation of Compliance (AOC), access to the latest versions of these documents can be requested through the Cisco Trust Portal. Other relevant documentation such as the Consensus Assessment Initiative Questionnaire (CAIQ) or ISO compliances may also be available through this portal.

For questions on missing or outdated documentation, please open a Support case with Cisco Meraki Support, referencing the details of specific documentation required.

Summary

Additional notes

Access points running older firmware

There is a known issue with Dashboard and Legacy AP that are running older firmware and the PCI reporting function. Networks with AP that cannot run r27.x or r28.x firmware, but are running the latest available firmware for their platform, i.e. MR32/ 26.8.3, will seemingly fail a PCI report. Meraki is working on getting the reporting functionality updated to accurately reflect the software patch compliance of an AP that is running the latest firmware available for it.

Please note that the issue is cosmetic only and does not indicate a true out-of-compliance for the network(s) if, the only failure is 6. 2 out-of-date software.

Was this article helpful?

Article type

Topic

Stage

Final
Tags
1. PCI

Discontinued models and recommended replacements

Your browser does not support JavaScript. Please turn it on for the best experience.

Support

Downloads
Frequently Asked Questions
Technical Support Forum
Contact technical support
Warranty Policy
Lists of compatible devices

Where to buy?

Stores
System integrators
Sub-distributors
Distributors
Project Distributors

Community

Russia / Russian

TP-Link, Reliably Smart

Category	Models discontinued	Status	Recommended replacement
Wireless Router	Archer C3200	EOL	Archer C4000
	Archer C59	EOL	Archer C1200
	Archer C50	EOL	Archer C50(RU)
	Archer C20	EOL	Archer C20(EN)
	TL-WDR4300	EOL	Archer C6
	TL-WDR3600	EOL	Archer C6
	TL-WDR3500	EOL	Archer C20(RU)
	TL-WR1045ND	EOL	Archer C6
	TL-WR1043ND	EOL	Archer C6
	TL-WR1042ND	EOL	TL-WR940N 450M
	TL-WR942N	EOL	TL-WR842N
	TL-WR941ND 450M	EOL	TL-WR940N 450M
	TL-WR941ND	EOL	TL-WR940N 450M
	TL-WR940N	EOL	TL-WR940N 450M
	TL-WR843ND	EOL	TL-WR842N
	TL-WR842ND	EOL	TL-WR842N
	TL-WR842ND(EN)	EOL	TL-WR842N
	TL-WR841HP	EOL	TL-WR841N
	TL-WR841ND	EOL	TL-WR841N
	TL-WR743ND	EOL	TL-WR840N
	TL-WR741ND	EOL	TL-WR840N
	TL-WR740N	EOL	TL-WR840N
	TL-WR720N	EOL	TL-WR820N
	Archer C2	EOL	Archer C6
	Archer C2(RU)	EOL	Archer C6
	Archer C59	EOL	Archer C6
	TL-WR902AC	EOL	TL-MR3020
	TL-WR810N	EOL	TL-WR820N
	TL-WR802N	EOL	TL-WR820N
	TL-WR702N	EOL	TL-MR3020
	TL-MR3220	EOL	TL-WR842N
Repeater/AP	RE350	EOL	RE305
	RE210	EOL	RE205
	TL-WA890EA	EOL	RE200
	TL-WA830RE	EOL	TL-WA850RE
	TL-WA750RE	EOL	TL-WA854RE
	TL-WA730RE	EOL	TL-WA854RE
	TL-WA701ND	EOL	TL-WA801ND/EAP110
	TL-WA820RE	EOL	TL-WA850RE
	RE370K	EOL	RE270K
3G/LTE MIFI/Router	M5360	EOL	M7350
	M5350	EOL	M7200
	M5250	EOL	M7200
	M7310	EOL	M7350
	TL-MR3420	EOL	TL-WR842N
	TL-MR3040	EOL	TL-MR3020
Business WiFi	TL-WA7510N	EOL	CPE510
	TL-WA7210N	EOL	CPE210
	TL-WA5210G	EOL	CPE210
	CPE520	EOL	CPE610
	EAP330	EOL	EAP245
	EAP220	EOL	EAP225
	EAP120	EOL	EAP115
	TL-WA5110G	EOL	TL-WA801ND/EAP110
USB/PCI/PCI-E Adapter	Archer T1U	EOL	Archer T2U nano
	Archer T4UH	EOL	Archer T4U(EU)
	TL-WDN4800	EOL	Archer T6E
	TL-WDN3800	EOL	Archer T6E
	TL-WDN3200	EOL	Archer T2U
	TL-WN8200ND	EOL	TL-WN822N
	TL-WN7200ND	EOL	TL-WN722N
	TL-WN821NC	EOL	TL-WN821N
	TL-WN723N	EOL	TL-WN821N
	TL-WN751ND	EOL	no replacement
	TL-WN722NC	EOL	TL-WN722N
	TL-WN721NC	EOL	TL-WN727N
	TL-WN721N	EOL	TL-WN727N
	TL-WN951N	EOL	no replacement
	TF-3200	EOL	TL-WN881ND
	TF-3239DL	EOL	TG-3468
	TG-3269	EOL	TG-3468
	TL-WN751N	EOL	TL-WN781ND
ADSL/VDSL	TD-W9977	EOL	TD-W8960N
	TD-W9970B	EOL	no replacement
	Archer D20	EOL	Archer VR300
	TD-W8961NB	EOL	no replacement
	TD-W8961ND	EOL	TD-W8961N
	TD-W8951ND	EOL	TD-W8961N
	TD-W8951NB	EOL	no replacement
	TD-W8950ND	EOL	TD-W8961N
	TD-W8151N	EOL	TD-W8901N
	TD-8817	EOL	TD-W8961N
	TD-8816	EOL	TD-W8961N
	TD-8616	EOL	TD-W8961N
	TD-VG3631	EOL	TD-W8968
	TD-8840T	EOL	TD-W8901N
PLC	TL-WPA4220	EOL	TL-WPA4220KIT
	TL-WPA2220	EOL	TL-WPA4220KIT
	TL-PA6010KIT	EOL	TL-PA4010KIT
	TL-PA6010	EOL	TL-PA4010KIT
	TL-PA4030	EOL	TL-PA4010KIT
	TL-PA4020KIT	EOL	TL-PA4010KIT
	TL-WPA2220KIT	EOL	TL-PA4020KIT
	TL-PA4010P	EOL	TL-PA4010PKIT
	TL-PA4010	EOL	TL-PA4010KIT
	TL-PA551	EOL	TL-PA4010PKIT
	TL-PA511	EOL	TL-PA4010KIT
	TL-PA411	EOL	TL-PA4010KIT
	TL-PA2010	EOL	TL-PA2010KIT
	TL-PA2010P	EOL	TL-PA4010PKIT
	TL-PA2010KIT	EOL	TL-PA4010PKIT
	TL-PA4010PTKIT	EOL	TL-PA4010PKIT
	TL-PA7020KIT	EOL	TL-PA7020PKIT
	TL-PA8030PKIT	EOL	TL-PA8010PKIT
	TL-WPA281	EOL	TL-WPA4220KIT
	TL-PA2010PKIT	EOL	TL-PA4010PKIT
IP Camera	TL-SC4171G	EOL	NC260
	NC210	EOL	NC260
	NC230	EOL	NC260
	NC220	EOL	NC260
	NC200	EOL	NC260
	NC250	EOL	NC260
	TL-SC3430	EOL	NC260
	TL-SC3230N	EOL	NC260
	TL-SC3230	EOL	NC260
	TL-SC3171G	EOL	NC260
	TL-SC3171	EOL	NC260
	TL-SC3130G	EOL	NC260
	TL-SC3130	EOL	NC260
	TL-SC2020N	EOL	NC260
	TL-SC2020	EOL	NC260
Antenna&Accessory	TL-ANT24EC12N	EOL	no replacement
	TL-ANT24EC6N	EOL	TL-ANT24EC5S/TL-ANT24EC3S
	TL-ANT24PT	EOL	TL-ANT24PT3
	TL-ANT2406A	EOL	TL-ANT2409A
	TL-ANT2409B	EOL	TL-ANT2424B
	TL-ANT2414B	EOL	TL-ANT2424B
	TL-ANT2408C	EOL	TL-ANT2408CL
	TL-ANT5823B	EOL	no replacement
	TL-ANT24SP	EOL	no replacement
	TL-ANT2405C	EOL	TL-ANT2408CL
	TL-ANT5830B	EOL	no replacement
	TL-ANT2405CL	EOL	TL-ANT2408CL
Switch	T2700G-28TQ	EOL	T3700G-28TQ
	TL-SG2008	EOL	T1500G-8T
	TL-SG2216	EOL	T1600G-18TS
	TL-SG2109WEB	EOL	T2500G-10TS
	TL-SL2210WEB	EOL	T2500G-10TS
	TL-SL2218WEB	EOL	T1600G-18TS
	TL-SL2428WEB	EOL	T2500-28TC
	TL-SL2452WEB	EOL	T1600G-52TS
	TL-SG2210P	EOL	T1500G-10MPS
	TL-SG3216	EOL	T2600G-18TS
	TL-SG5428	EOL	T2600G-28TS
	TL-SG5412F	EOL	T2600G-28SQ
	TL-SG3424	EOL	T2600G-28TS
	TL-SG2424	EOL	T1600G-28TS
	TL-SG2424P	EOL	T1600G-28PS
	TL-SL5428E	EOL	T2500-28TC
	TL-SL3452	EOL	T2600G-52TS
	TL-SL3428	EOL	T2500-28TC
	TL-SL2428	EOL	T2500-28TC
	TL-SG3424P	EOL	T2600G-28MPS
	TL-SL1351	EOL	T1600G-52TS
	TL-SL1210	EOL	T2500G-10TS
	TL-SL1117	EOL	T1600G-18TS
	TL-SL2452	EOL	T1600G-52TS
	TL-SL2210	EOL	T2500G-10TS
	TL-SL5428E V3	EOL	T2500-28TC
	TL-SL1226	EOL	T2500-28TC
	TL-SG2452	EOL	T1600G-52TS
	TL-SL2218	EOL	T1600G-18TS
	TL-SG3210	EOL	T2500G-10TS
	TL-SG1008	EOL	TL-SG108
Wired Router	TL-ER604W	EOL	no replacement
	TL-R860	EOL	TL-R480T+
	TL-R460	EOL	TL-R470T+
Mobile Accessory	TL-PB20100	EOL	TL-PB10000
	TL-PB6700	EOL	TL-PB10000
	TL-PBG13400	EOL	TL-PB10000
	TL-PBG6700	EOL	TL-PB10000
	TL-PB5200	EOL	TL-PB10000
	TL-PBG3350	EOL	TL-PB10000
	TL-PB2600	EOL	TL-PB10000
	PB50	EOL	TL-PB10000
	TL-AC210	EOL	no replacement
	CP230	EOL	no replacement
	CP220	EOL	no replacement
	UP540	EOL	no replacement
	UP525	EOL	no replacement
	UP220	EOL	no replacement
Smart Home	LB130	EOL	KL130
	LB120	EOL	KL120
	LB110	EOL	KL110
	LB100	EOL	KL110
	RE270K	EOL	RE360
	BS1001	EOL	no replacement

8-Port Low Profile PCI Express RS-232 Card, Moxa

Tire
Tire type

PCI Express
Connector for device

VHDCI 68 (requires external splitter)
Low Profile (2U) Chassis Mountable

Yes
PCI Express bus modification

PCI Express x1

Serial communication parameters
Serial Controller

16C550C
Number of RS-232 ports

8
Transmitted signals

RS-232: TxD, RxD, DTR, DSR, RTS, CTS, DCD, GND
Data bit

5, 6, 7, 8
Parity

no, even, odd, 0, 1
Stop bits

1, 1. 5, 2
Data flow management

RTS/CTS, XON/XOFF
Baud rate, bps

50 ~ 921600

Power Requirements
Current consumption

1.225 mA at 3.3 V

Operating conditions
Operating temperature, °C

0 ~ +55
Storage temperature, °C

-20 ~ +85
Operating humidity, %

5 ~ 95

Protection
Surge protection kV

15

Operating system
Drivers for OS

DOS
Linux 2.4.x
Linux 2.6.x
Linux 3.x
QNX 6
SCO OpenServer
Solaris 10
UnixWare 7
Windows 2008 R2/2012/2012 R2 (x64) 9 1712 Windows 95/98/ME/NT/2000
Windows XP/2003 /Vista/2008/7/8/8.1/10 (x86/x64)

Dimensions and weights
Dimensions, mm

64. 42 x 102

Assembly
Assembly

To computer

Availability of international certificates
Electromagnetic compatibility (EMI)

CISPR 32
FCC Part 15 Subpart B Class B
Electromagnetic compatibility (EMS)

IEC 61000-4-11
IEC 61000-4-2 (ESD)
IEC 61000-4-3 RS
IEC 61000-4-4 (EFT)
IEC 61000-4-5 Surge
IEC 61 000-4-6 CS
IEC 61000-4-8
Electromagnetic compatibility (EMC)

EN 55032/24
Mean time between failures (MTBF), hours

2351336

Warranty period
Warranty period

5 years

Product page on the English site
Link to moxa.com

http://www.moxa.com/product/CP-168EL-A.htm

Documentation

Datasheet (English): download (1 MB)

Hardware Manual (English): download (0. 3 MB)

Hardware Manual (Russian): download (64 KB)

User Manual (English): download (12 MB)

PCI Express Smart Card Quick Installation Guide (Russian): download (0.3 MB)

Drawing for AutoCAD 2D (dwg): download (0.8 Mb)

3D model (stp): download (0.1 Mb)

Software 3.1 dated 09/06/2022): download (1 Mb):

Changelog: download (0.1 Mb)
Windows 10
Windows 7
Windows 8
Windows 8.1
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Windows Server 2022

Driver for Windows 2008 and earlier (version 1.24 dated 10/18/2017): download (0.8 MB):

Changelog: download (0.1 MB)
Windows 2000
Windows Server 2003
Windows Server 2008
Windows Vista
Windows XP

Driver for Windows ME and earlier (version 5. 11 dated 07/11/2010): download (0.3 Mb):

List of changes: download (0.1 Mb)
Windows 95
Windows 98
Windows 98 SE
Windows ME

Driver for Linux Kernel 2.x.x (version 2.0 dated 12/31/2019): download (0.2 Mb):

Changelog: download (0.1 Mb)
Linux 2.4.x
Linux 2.6.x

Driver for Linux Kernel 3.x.x (version 3.0 dated 12/31/2019): download (0.2 Mb):

Changelog: download (0.1 Mb)
Linux 3.x

MSB Linux Kernel 5.x.x driver (version 5.1 dated 10/25/2021): download (0.1 Mb)

Changelog: download (0.1 Mb)
Linux Kernel 5.x

MSB Linux Kernel 4.x.x driver (version 4.1 dated 10/25/2021): download (0.1 Mb)

Changelog: download (0.1 Mb)
Linux Kernel 4.x

Driver for QNX 6.x (version 1.1 dated February 11, 2010): download (0.1 Mb)

List of changes: download (0. 1 Mb)

Driver for DOS (version 1.12 dated 03/31/2014): download (0.6 Mb)

Changelog: download (0.1 Mb)

Driver for SCO OpenServer 5 (version 1.13 dated 03/30/2014): download (0.2 Mb)

Changelog: download (0.1 Mb)

Driver for SCO OpenServer 6 (version 1.13 dated 03/30/2014): download (0.3 Mb)

Changelog: download (0.1 Mb)

Driver for Solaris 10 (version 1.1 dated 03/31/2012): download (0.1 Mb)

List of changes: download (0.1 Mb)

Driver for Windows XP Embedded (version 1.16 dated February 9, 2010): download (0.3 Mb)

Changelog: download (0.1 Mb)

PComm Lite — utility for Windows (version 1.6 dated 05/14/2012): download (2 Mb)

Windows 2000
Windows 7
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Vista
Windows XP

ViewCOM (version 1.