- Equipment List
- General Guidelines
- Setting Up the Lab
- Practice Lab 1 Exercises Section 1.0: Basic Configuration (10 points)
- Section 2.0: Routing Configuration (25 points)
- Section 3.0: ISDN Configuration (8 points)
- Section 4.0: PIX Configuration (5 points)
- Section 5.0: IPSec/GRE Configuration (10 points)
- Section 6.0: IOS Firewall + IOS IDS Configuration(10 points)
- Section 7.0: AAA (7 points)
- Section 8.0: Advanced Security (10 points)
- Section 9.0: IP Services and Protocol-Independent Features (10 points)
- Section 10.0: Security Violations (5 points)
- Verification, Hints, and Troubleshooting Tips
- Section 1.0: Basic Configuration
- Section 2.0: Routing Configuration
- Section 3.0: ISDN Configuration
- Section 4.0: PIX Configuration
- Section 5.0: IPSec/GRE Configuration
- Section 6.0: IOS Firewall Configuration
- Section 7.0: AAA
- Section 8.0: Advanced Security
- Section 9.0: IP Services and Protocol-Independent Features
- Section 10.0: Security Violations
Section 5.0: IPSec/GRE Configuration
5.1: IPSec
5.1.1: IPSec LAN-to-LAN Using Preshared
Configure a LAN-to-LAN IPSec between the PIX and R4. The key is the interesting traffic for IPSecthe IPSec access list, which should be for UDP port 45000, the postoffice protocol communication between the IDS and Director. You can also configure an access list for UDP traffic from host to host10.50.13.82 to 10.50.31.60.
5.1.2: Advanced IPSec LAN-to-LAN
Configure GRE traffic in section 5.2. IPSec access list should be host-to-host and use tunnel mode. Configure ISAKMP keepalive to check the connectivity. If the peer does not respond, phase1 SA will go down and this will also take down the phase 2 SAs.
Also remember to configure no ip route-cache on all GRE tunnels and physical interfaces where crypto map is applied.
5.2: GRE
This is a tricky one. Configure GRE between R3 and R6. You need to configure static translation on PIX for loopback2 to the same address for GRE tunnel on R3 to peer as the GRE destination.
Furthermore, modify the outside access list on PIX to allow ESP and UDP/500 from host 133.133.133.133 to 166.166.166.166. You do not need to allow GRE since the packets will be encrypted as per section 5.1.2:
Redistribute OSPF into EIGRP 100 with a route map to match only loopbacks in area30. The example that follows is for the redistribution configuration on R3:
access-list outside permit esp host 133.133.133.133 host 166.166.166.166 (hitcnt=79166) access-list outside permit udp host 133.133.133.133 host 166.166.166.166 eq isakmp (hitcnt=99) static (inside,outside) 166.166.166.166 166.166.166.166
router eigrp 100 redistribute ospf 110 route-map o2e. ! access-list 2 permit 30.30.1.0 access-list 2 permit 30.30.2.0 access-list 2 permit 30.30.3.0 access-list 2 permit 30.30.4.0 access-list 2 permit 30.30.5.0 access-list 2 permit 30.30.6.0 ! route-map o2e permit 10 match ip address 2
We are not done yet.
Now, if you do a show ip route on R6, you will see that it is learning all the routes via the GRE tunnel interface as expected. See the routing table on R6:
r6#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 10.10.6.1 to network 0.0.0.0 D EX 30.30.1.0 [170/297270016] via 36.36.36.3, 00:13:47, Tunnel63 D EX 30.30.2.0 [170/297270016] via 36.36.36.3, 00:13:47, Tunnel63 D EX 30.30.3.0 [170/297270016] via 36.36.36.3, 00:13:47, Tunnel63 D EX 30.30.4.0 [170/297270016] via 36.36.36.3, 00:13:47, Tunnel63 D EX 30.30.5.0 [170/297270016] via 36.36.36.3, 00:13:47, Tunnel63 D EX 30.30.6.0 [170/297270016] via 36.36.36.3, 00:13:47, Tunnel63 R* 0.0.0.0/0 [120/1] via 10.10.6.1, 00:00:16, Ethernet0/1
The question requires pinging the even networks via the tunnel and odd networks via the PIX. In doing so, it is allowed to use an ACL with one line only.
The solution is "policy routing." You need to create a policy route to match the odd networks and set the next hop to the PIX inside interfacethat is, 10.10.6.1and apply it in global mode, as packets will originate from R6 when testing:
ip local policy route-map next-hop ! access-list 102 permit ip any 30.30.1.0 0.0.254.255 ! route-map next-hop permit 10 match ip address 102 set ip next-hop 10.10.6.1
The way to confirm if it is working is to turn on debug icmp trace on PIX, and ping the odd networks. You will see the packets flowing through, but when you ping even networks, it won't show, as they will be traversing as GRE/IPSec packets and not ICMP traffic. The following example demonstrates this procedure.
pix# debug icmp trace ICMP trace on Warning: this may cause problems on busy networks r6#ping 30.30.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.30.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 104/179/200 ms r6#ping 30.30.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.30.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms pix# debug icmp trace ICMP trace on Warning: this may cause problems on busy networks pix# 190: Outbound ICMP echo request (len 72 id 58378 seq 1947) 36.36.36.6 > 10.50.31.1 >30.30.1.1 191: Inbound ICMP echo reply (len 72 id 17920 seq 1947) 30.30.1.1 > 10.50.31.1 > 36.36.36.6 192: Outbound ICMP echo request (len 72 id 58634 seq 1947) 36.36.36.6 > 10.50.31.1 > 30.30.1.1 193: Inbound ICMP echo reply (len 72 id 18176 seq 1947) 30.30.1.1 > 10.50.31.1 > 36.36.36.6 194: Outbound ICMP echo request (len 72 id 58890 seq 1947) 36.36.36.6 > 10.50.31.1 > 30.30.1.1 195: Inbound ICMP echo reply (len 72 id 18432 seq 1947) 30.30.1.1 > 10.50.31.1 > 36.36.36.6 196: Outbound ICMP echo request (len 72 id 59146 seq 1947) 36.36.36.6 > 10.50.31.1 > 30.30.1.1 197: Inbound ICMP echo reply (len 72 id 18688 seq 1947) 30.30.1.1 > 10.50.31.1 > 36.36.36.6 198: Outbound ICMP echo request (len 72 id 59402 seq 1947) 36.36.36.6 > 10.50.31.1 > 30.30.1.1 199: Inbound ICMP echo reply (len 72 id 18944 seq 1947) 30.30.1.1 > 10.50.31.1 > 36.36.36.6
As you can see, that ping works for both the odd and even networks from R6, but ICMP packets are only seen when pinging the odd network, not the even network.
Note that the return echo-reply packets are sent back to the 36.36.36.6 IP address, which is the tunnel IP on R6.
You need to create a static route on PIX for this network, or you will notice that the odd network pings are unsuccessful.