I have the following ClassB network 172.31.0.0/16 that I’m trying to create an access list for. I’d like to allow 172.31.240.0/24 but deny all else, so I’m looking the best way to accomplish this with 2 acl lines.

Answer:

The best way to accomplish the above is to explicitly allow the subnet you want and then deny the whole Class B network as following:

access-list 110 permit ip 172.31.240.0 0.0.0.255
access-list 110 deny ip 172.31.0.0 0.0.255.255

Another option with just one ACL entry would be to permit only the subnet 172.31.240.0/24 and thats it. No other ACL entries are needed since there is an implicit deny at the end of the access list statement.

Unfortunately, there are cases that even if the two TCP endpoints negotiate a certain size of TCP MSS, one of the devices sends data to the other device which is larger than the MSS. With the new version of the Cisco ASA (or PIX) firewall with software version 7.x and up, the above situation is not accepted by the firewall which drops the packets that do not adhere to the negotiated MSS size. The firewall does this to protect the devices from buffer overflow attacks.

The problem addressed here is when an FTP Client located on the INSIDE of a Cisco ASA firewall, can not access an FTP Server machine located on the OUTSIDE of the firewall, as shown on the diagram below. The same problem can also happen with any TCP application (e.g HTTP), not just FTP.

The initial firewall configuration is as following

pixfirewall(config)#interface Ethernet0
pixfirewall(config-if)#speed 100
pixfirewall(config-if)#duplex full
pixfirewall(config-if)#nameif outside
pixfirewall(config-if)#security-level 0
pixfirewall(config-if)#ip address 192.168.9.30 255.255.255.0
pixfirewall(config-if)#exit
pixfirewall(config)#interface Ethernet1
pixfirewall(config-if)#speed 100
pixfirewall(config-if)#duplex full
pixfirewall(config-if)#nameif inside
pixfirewall(config-if)#security-level 100
pixfirewall(config-if)#ip address 10.0.0.1 255.255.255.0
pixfirewall(config-if)#exit
pixfirewall(config)#global (outside) 1 interface
pixfirewall(config)#nat (inside) 1 10.0.0.0 255.0.0.0
pixfirewall(config)#route outside 0.0.0.0 0.0.0.0 192.168.9.2 1

The problem is observed when looking at the logs of the firewall:

Show log:

Sep 19 2007 06:55:58: %ASA-4-419001: Dropping TCP packet from INSIDE:10.0.0.2/38003 to OUTSIDE:192.168.9.2/21, reason: MSS exceeded, MSS 1390, data 1460

The log output above shows that the FTP client and server negotiated an MSS value of 1390, but the data sent is 1460, therefore the firewall drops the packet.

There are two solutions for the MSS exceeded problem, one which can be applied globally on the ASA firewall, and one which can be applied for the specific connection only:

Solution A (Applied Globally on Firewall)

There is a global command on the ASA firewall with which you can override the MSS value negotiated between the TCP devices. This command is shown below:

firewall(config)#sysopt connection tcpmss [minimum] bytes

The [minimum] keyword overrides the maximum segment size negotiated between the two devices to be no less than ‘bytes’. So to solve the problem above, configure the following:

firewall(config)#sysopt connection tcpmss minimum 1460

This will force the two devices to negotiate an MSS value to be no less than 1460, therefore the data sent can go through with no problems.

Solution B (Applied on the specific connection only)

The second workaround solution uses an access-list, a class map and a tcp-map to identify the specific FTP traffic between the client and the server, and allow the MSS to be exceeded only for this specific connection.

The configuration commands are shown below:

pixfirewall(config)#access-list ftp-list permit tcp host 10.0.0.2 host 192.168.9.2
pixfirewall(config)#
pixfirewall#configure terminal
pixfirewall(config)#
pixfirewall(config)#class-map ftp-map
pixfirewall(config-cmap)#match access-list ftp-list
pixfirewall(config-cmap)#exit
pixfirewall(config)#tcp-map mss-map
pixfirewall(config-tcp-map)#exceed-mss allow
pixfirewall(config-tcp-map)#exit
pixfirewall(config)#policy-map ftp-map
pixfirewall(config-pmap)#class ftp-map
pixfirewall(config-pmap-c)#set connection advanced-options mss-map
pixfirewall(config-pmap-c)#exit
pixfirewall(config-pmap)#exit
pixfirewall(config)#service-policy ftp-map interface outside
pixfirewall#

The configuration above will allow the MSS to be exceeded only between the FTP client and FTP server connections.

If you want to learn how to configure and implement any Cisco ASA 5500 v7.x and v8.x Firewall, check out the following excellent Book:

Whats Included in the eBook

	Getting Started with Cisco Firewalls (User Interface, Access Modes)
	File Management
	Security Levels (Traffic Flow between Security Levels)
	Basic Firewall Configuration (Basic Configuration Steps)
	Configuring Network Address Translation (NAT, PAT, Static NAT, Port Redirection)
	Using Access Control Lists (ACLs)
	Controlling Inbound and Outbound Traffic with ACLs
	ACL Object Groups
	Configuring VLANs and Subinterfaces
	IPSEc VPNs (site-to-site VPN, Remote Access VPN, VPN client)
	Configuring Active/Standby Stateful Failover

GET YOUR EBOOK HERE

A Cisco Router with the proper IOS version can make an excellent IPSEC VPN termination device, and can be used to securely connect two distant LANs over an untrusted network, such as the Internet. In our example below, we use two Cisco 800 series broadband routers to create an IPSEC VPN tunnel between two offices over a DSL broadband connection via the Internet.

A sample of the configuration concerning the example above is shown below:

hostname siteA  !
  crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
  crypto isakmp key ciscokey address 200.200.200.1
  !
  crypto ipsec transform-set TRANSFORM esp-3des esp-sha-hmac
  !
  crypto map VPN 10 ipsec-isakmp
 set peer 200.200.200.1
 set transform-set TRANSFORM
 match address 100
  !
  interface FastEthernet0
  !
  interface FastEthernet1
  !
  interface FastEthernet2
  !
  interface FastEthernet3
  !        
  interface FastEthernet4
 ip address 200.200.100.1 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
 crypto map VPN
  !
  interface Vlan1
 ip address 10.10.149.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
  !
  ip classless
  ip route 0.0.0.0 0.0.0.0 200.200.100.2
  !
  ip nat inside source list 101 interface FastEthernet4 overload
  !
  access-list 100 permit ip 10.10.149.0 0.0.0.255 10.10.1.0 0.0.0.255
  access-list 101 deny   ip 10.10.149.0 0.0.0.255 10.10.1.0 0.0.0.255
  access-list 101 permit ip 10.10.149.0 0.0.0.255 any

When using the IPSEC Key Exchange (IKE) mechanism for setting up the VPN tunnel, there are two Phases in the ISAKMP (Internet Security Association and Key Management Protocol) operation:

• Phase 1: In this phase the two nodes verify their identity and establish an initial secure communication channel for further IKE communication. The parameters negotiated in this Phase include the Encryption algorithm (e.g 3DES), a hash algorithm (MD5 or SHA), an authentication method (e.g pre-shared keys), and a Diffie-Hellman group.
• Phase 2: Using the secure communication channel established in Phase 1, the two nodes in Phase 2 negotiate Security Associations (SA) for IPSEC Transforms (AH for authentication or ESP for Encryption).

Therefore, in order to efficiently troubleshoot the IPSEC VPN operation, we need to check the two phases independently, starting always with Phase 1 to see if it has been established correctly, and then verifying Phase 2 establishment.

Phase 1:

The following command shows the status of Phase 1 negotiation:

SiteA#show crypto isakmp sa

  IPv4 Crypto ISAKMP SA

  dst                                src             state                  conn-id slot status

  200.200.200.1    200.200.100.1    QM_IDLE           1001    0 ACTIVE

  From the output above we can see the public IP addresses 200.200.200.1 and 200.200.100.1 used as source and destination between the two Site Routers. The most important field to check here is the ‘state’ field which must be ‘QM_IDLE’ in order for Phase 1 to be correctly established. Other possible states in this field are:

Phase 2:

To verify Phase 2 operation use the following command:

SiteA#show crypto ipsec sa

interface: FastEthernet4
      Crypto map tag: VPN, local addr 200.200.100.1
   protected vrf: (none)
     local  ident (addr/mask/prot/port): (10.10.149.0/255.255.255.0/0/0)
     remote ident (addr/mask/prot/port): (10.10.1.0/255.255.255.0/0/0)
     current_peer 200.200.200.1 port 500
       PERMIT, flags={origin_is_acl,}
      #pkts encaps: 1843, #pkts encrypt: 1843, #pkts digest: 1843
      #pkts decaps: 2618, #pkts decrypt: 2618, #pkts verify: 2618
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts compr. failed: 0
      #pkts not decompressed: 0, #pkts decompress failed: 0
      #send errors 0, #recv errors 0
     local crypto endpt.: 200.200.100.1, remote crypto endpt.: 200.200.200.1
       path mtu 1500, ip mtu 1500
       current outbound spi: 0x8BF4C2A1(2348073633)
     inbound esp sas:
        spi: 0x812A50F7(2167034103)
  transform: esp-3des esp-sha-hmac ,

The important points to watch in the output above are the pkts encrypt and pkts decrypt. These values show if packets are successfully encrypted and decrypted inside the VPN tunnel. The output above shows that Phase 2 is succesfuly established.

If you see only packets encrypted without any decrypted packets (or vice-versa), this means that the VPN tunnel works only one-way, which is not correct. You can then use the command: debug crypto ipsec to get a more detailed explanation why Phase 2 failed.