SmallNetBuilder

Firewall

The 3120 has a very capable firewall supporting Access Control Lists (ACLs), Access Control Policies (ACPs), NAT, and Stateful Packet Inspection (SPI). ACLs are used to permit or deny specific types of network traffic based on origination and destination IP addresses and ports. In conjunction with VLANs and separate subnets, ACLs can be used to control not only the traffic that can enter the network, but also traffic within the network.

To enable remote access to the 3120, an ACL has to be created and the Access Policy for the Public interface has to edited, which can be accomplished through the GUI. Figure 10 shows an Access Policy where I've enabled remote access through the Public/WAN interface for HTTPS and SSL protocols.

Figure 10: Remote Access enabled

Applying and saving these configurations resulted in the following lines being added to the running configuration, viewable in the CLI with the show run command. This is a good way to start learning AOS commands.

ip access-list extended web-acl-8
remark Remote Access
permit tcp any  any eq https   log
permit tcp any  any eq ssh   log
ip policy-class Public
allow list web-acl-8 selfinterface eth 0/1
interface eth 0/1
access-policy Public

Access Control Policies can be used in conjunction with ACLs for port forwarding. This is an area where you'll probably want to use the CLI, since the Web GUI has some limitations. For example, the way to set up port forwarding in the GUI is to run the Firewall Wizard. But the problem I had with the Firewall Wizard was that it consistently disabled incoming and outgoing VPN traffic, forcing a reconfiguration of settings for restore full VPN connectivity.

I also wanted to forward TCP port 5001 traffic through the 3120's Public (WAN) Interface to a PC on the LAN side. An extended ACL is needed to permit traffic to the IP address/DNS of the WAN interface and corresponding port. The commands are as follows:

ip access-list extended dougsacl
permit tcp any  hostname (mydyndns.com) eq 5001 log

The log keyword at the end of the above statement triggers a log entry every time the ACL is activated. In addition to this ACL, traffic to port 5001 has to be mapped through the NAT function of the router. This is achieved with an entry to the ACP defined for the Public Interface. The statement below tells the 3120 that traffic matching the ACL dougsacl should be forwarded to the PC with the IP Address 10.10.12.11.

ip policy-class Public
nat destination list dougsacl address 10.10.12.11

VPN

The 3120 supports up to five IPsec Site-to-Site VPN tunnels. It also supports IPsec Client connections, but does not support SSL Client VPN connections. I was disappointed to find that ADTRAN doesn't include even a single license for IPsec Client VPN software with the 3120, since I have seen less expensive routers that do.

In my testing, I configured the 3120 to run IPsec Site-to-Site VPN tunnels tunnels to both a Netgear FVS336G router and a SonicWall TZ190W, simultaneously. The NetVanta VPN Menu has both a Wizard and a manual option for configuration. But to set up a static connection to a remote Dynamic DNS domain, I found it necessary to use the manual configuration option, since the Wizard would take only an IP address for the remote Peer Address.

Figure 11: VPN Peer configuration

VPN configuration took a bit of trial and error to find the right combinations. To enable the ADTRAN-Netgear Site-to-Site tunnel, I set up a static VPN Peer to the Dynamic DNS address of the Netgear. The tunnel came up using Aggressive Mode for IKE (Internet Key Exchange), Domain Names for Local and Remote Identification, and a Preshared Key for authentication.

IPsec configurations were flexible, however, and I had success with PFS (Perfect Forward Secrecy) enabled or disabled, 3DES or AES encryption, as well as MD5 or SHA-1 hashing algorithms. Of course, each of the options had to match on both the ADTRAN and Netgear. Figure 12 shows the configuration screen where IKE and IPsec options are selected.

Figure 12: IKE and IPsec settings

To enable the ADTRAN to SonicWall Site-to-Site tunnel, I tested the same Phase 1 and Phase 2 settings as with the Netgear, but could only get the ADTRAN-SonicWall VPN tunnel to come up using AH (Authentication Headers) instead of ESP (Encapsulating Security Payload) for the Phase 2 configurations. With ESP configured on both sides of the ADTRAN-SonicWall tunnel, Phase 1 was successful but Phase 2 negotiation failed.