Cisco Cisco ASA 5555-X Adaptive Security Appliance - No Payload Encryption 문제 해결 가이드

다운로드
페이지 6
Solutions to the Problem
There are several potential solutions to this issue. Depending on the network topology and the specific
situation, one solution might be easier to implement than another.
Solution 1− Static Route for Null0 Interface (ASA Version 9.2.1 and Later)
When you send traffic to a Null0 interface, it causes the packets destined to the specified network to be
dropped. This feature is useful when you configure Remotely Triggered Black Hole (RTBH) for Border
Gateway Protocol (BGP). In this situation, if you configure a route to Null0 for the remote access client
subnet, it forces the ASA to drop traffic destined to hosts in that subnet if a more specific route (provided by
Reverse Route Injection) is not present.
route Null0 10.255.0.0 255.255.255.0
Solution 2 − Use a Different IP Pool for VPN Clients 
This solution is to assign the remote VPN users an IP address that does not overlap with any internal network
subnet. This would would prevent the ASA from forwarding packets destined to that VPN subnet back to the
inside router if the VPN user was not connected.
Solution 3 − Make the ASA Routing Table More Specific for Internal
Routes
This solution is to ensure the routing table of the ASA does not have any very broad routes that overlap with
the VPN IP pool. For this specific network example, remove the 10.0.0.0/8 route from the ASA and configure
more specific static routes for the subnets that reside off of the inside interface. Dependent upon the number
of subnets and the network topology, this might be a large number of static routes and it might not be
possible. 
Solution 4 − Add a More Specific Route for the VPN Subnet Back Out of
the Outside Interface
This solution is more complicated that the others that are described in this document. Cisco recommends that
you attempt to use the other solutions first due to the situation that is described in the Note later in this
section. This solution is to prevent the ASA from forwarding IP packets sourced from the VPN IP subnet back
to the internal router; you can do this if you add a more specific route for the VPN subnet out of the outside
interface. Since this IP subnet is reserved for outside VPN users, packets with a source IP address from this
VPN IP subnet should never arrive inbound on the ASA inside interface. The easiest way to achieve this is to
add a route for the remote access VPN IP Pool out of the outside interface with a next hop IP address of the
upstream ISP router.
In this network topology example, that route would look like this:
route outside 10.255.0.0 255.255.255.0 198.51.100.1
In addition to this route, add the ip verify reverse−path inside command in order to cause the ASA to drop
any packets received inbound on the inside interface sourced from the VPN IP subnet due to the more
preferred route that exists on the outside interface:
ip verify reverse−path inside