| 1. | The VPN session is established, but no traffic, or just one-way traffic, is passing between the Boston firewall and Los Angeles firewall. Ellen starts debugging the problem using debug icmp trace . She pings the other end of the VPN node and gets the following results:
LOCAL-PIX(config)#
609001: Built local-host inside:10.10.2.21
106014: Deny inbound icmp src outside:10.10.10.31 dst
inside:10.10.2.21 (type 8, code 0)106014: Deny inbound icmp src
outside:10.10.10.31 dst
inside:10.10.2.21 (type 8, code 0) 106014: Deny inbound icmp src
outside:10.10.10.31 dst
inside:10.10.2.21 (type 8, code 0)
106014: Deny inbound icmp src outside:10.10.10.31 dst
inside:10.10.2.21 (type 8., code 0)
106014: Deny inbound icmp src outside:10.10.10.31 dst
inside:10.10.2.21 (type 8, code 0)
609002: Teardown local-host inside:10.10.2.21duration 0:00:15
What do these results indicate and what could be causing this problem? How would you help Ellen resolve this issue? |
A1:
| Answer: The sysopt connection IPSec statement is missing from the configuration on the local PIX (Boston) and needs to be added. By default on the PIX Firewall, any inbound session must be explicitly permitted by a conduit or access list statement. With IPSec-protected traffic, the secondary access list check could be redundant. To ensure that IPSec-authenticated inbound sessions are always permitted, make sure that the configuration contains the following command:
sysopt connection permit-ipsec
|
| 2. | Eric cannot get the VPN tunnel to work from HQ to the Atlanta branch office. He starts a debug and gets the following results:
crypto-isakmp-process-block: src 10.10.10.40, dest 10.10.3.34
VPN Peer: ISAKMP: Added new peer: ip:10.10.10.40 Total VPN Peers:1
VPN Peer: ISAKMP: Peer ip:10.10.10.40 Ref cnt incremented to:1
Total VPN Peers:1
OAK-MM exchange
ISAKMP (0): processing SA payload. message ID = 0
ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 1
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (basic) of 2400
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): SA is doing pre-shared key authentication using id type ID-IPV4
-ADDR
return status is IKMP-NO-ERROR
crypto-isakmp-process-block: src 10.10.10.40, dest 10.10.3.34
OAK-MM exchange
ISAKMP (0): processing KE payload. message ID = 0
ISAKMP (0): processing NONCE payload. message ID = 0
ISAKMP (0): processing vendor id payload
ISAKMP (0): processing vendor id payload
ISAKMP (0): remote peer supports dead peer detection
ISAKMP (0): processing vendor id payload
ISAKMP (0): speaking to another IOS box!
return status is IKMP-NO-ERROR
crypto-isakmp-process-block: src 10.10.10.40, dest 10.10.3.34
OAK-MM exchange
ISAKMP (0): processing ID payload. message ID = 0
ISAKMP (0): processing HASH payload. message ID = 0
ISAKMP (0): SA has been authenticated
ISAKMP (0): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
ISAKMP (0): Total payload length: 12
return status is IKMP-NO-ERROR
crypto-isakmp-process-block: src 10.10.10.40, dest 10.10.3.34
ISAKMP (0): processing NOTIFY payload 24578 protocol 1
spi 0, message ID = 2457631438
ISAKMP (0): processing notify INITIAL-CONTACTIPSEC(key-engine): got a queue
event...
IPSEC(key-engine-delete-sas): rec'd delete notify from ISAKMP
IPSEC(key-engine-delete-sas): delete all SAs shared with 10.10.10.40
return status is IKMP-NO-ERR-NO-TRANS
crypto-isakmp-process-block: src 10.10.10.40, dest 10.10.3.34
OAK-QM exchange
oakley-process-quick-mode:
OAK-QM-IDLE
ISAKMP (0): processing SA payload. message ID = 133935992
ISAKMP: Checking IPSec proposal 1
ISAKMP: transform 1, ESP-DES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 28800
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP: authenticator is HMAC-MD5
IPSEC(validate-proposal): invalid local address 10.10.3.34
ISAKMP (0): atts not acceptable. Next payload is 0
ISAKMP (0): SA not acceptable!
ISAKMP (0): sending NOTIFY message 14 protocol 0
return status is IKMP-ERR-NO-RETRANS
crypto-isakmp-process-block: src 10.10.10.40, dest 10.10.3.34
ISAKMP (0:0): phase 2 packet is a duplicate of a previous packet.
What could be the cause of this problem? |
A2:
| Answer: The crypto map has not been applied to the correct interface. This is a common problem. Examining the Atlanta configuration, you notice that the crypto map has been applied to the DMZ instead of the outside interface. To fix the problem apply the crypto map to the outside interface using the following command:
crypto map BranchVPN interface outside
|
| 3. | Bruce is having problems establishing a VPN session to the Atlanta office. He gets the following debug results:
IPSEC(crypto-map-check): crypto map BranchVPN 20 incomplete. No peer or
access-list specified. Packet discarded
What is causing this problem, and how would you help Bruce successfully establish a VPN tunnel to the Atlanta office? |
A3:
| Answer: The crypto map statements on both peers must match each other. Examining the configuration reveals that the match address statement (for Atlanta) is missing from the HQ-PIX crypto map. The following command needs to be added to the HQ-PIX configuration:
crypto map BranchVPN 20 match address Atlanta
|
A4:
| Answer: Yes. Since the web administrator is coming from the inside interface, which has a security level of 100, and is going to the DMZ interface, which has a security level of 70, the traffic is allowed without a specific access list. Traffic from a higher-security-level interface is automatically allowed to traverse to a lower-security-level interface without a conduit or access list. |
A5:
| Answer: No. Although VPNs are configured between Los Angeles and the other two locations (and the sysopt connection permit IPSec line is in the configuration), the VPNs permit traffic only between each location's internal network segments. To access the web servers, you need to configure a VPN connection from the internal network in Los Angeles to the DMZ segments of Boston and Atlanta. |
A6:
| Answer: No. Although an access list allows traffic between the web server and the database server on port 1521, there is no route to the 10.10.11. X network segment. Therefore, traffic for the 10.10.11. X network is routed to the default route (192.168.1.254) instead of going to the internal web server. |
A7:
| Answer: Yes. An access list on the Boston firewall allows the inbound connection, and static IP address translations are configured on both firewalls. An access list is not required for the web server in Los Angeles to initiate outbound connections. |
A8:
| Answer: No. With the current configuration, the financial data retrieved from the database would traverse the Internet in the clear (without being encrypted). An attacker could watch this traffic and observe sensitive financial information. |
A9:
| Answer: No. The configured inbound access lists allow incoming FTP traffic to hosts 192.168.1.9 and 192.168.1.13. A static translation exists for 172.16.1.13, but there is no static translation for 172.16.1.9. |
A10:
| Answer: No. It appears that the access list named "Exchange" permits the users to access port 25 (SMTP) because it is applied to the outside interface. Unfortunately, only one access group can be applied to a specific interface for a specific traffic direction. The "inbound" access list has already been applied to the outside interface for incoming traffic. |
A11:
| Answer: By changing the access list statements labeled "Exchange" to "inbound," the statements become part of the existing access group that is already applied to the outside interface. |
لطفا منتظر باشید ...
