That is his question, why would it be needed, I mean the technical explanation. Im sure if you run the debug, without having a crypto map applied on the host facing interface, it will tell you "no atts acceptable". I am assuming if this has something to do with the identity or if the IP address is correctly put on the client and so on.
Mike From: eug...@koiossystems.com To: oszk...@gmail.com Date: Fri, 22 Jun 2012 05:56:45 +0000 CC: ccie_security@onlinestudylist.com Subject: Re: [OSL | CCIE_Security] dual armed EZVPN Is having only one crypto map a requirement? I’d have two different crypto maps applied to Fa0/1 and Ser0/1/0. From: Imre Oszkar [mailto:oszk...@gmail.com] Sent: Thursday, June 21, 2012 9:29 PM To: Eugene Pefti Cc: ccie security Subject: Re: [OSL | CCIE_Security] dual armed EZVPN R6#sh run | sec crypto crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp client configuration group EZ key cisco pool remote acl split crypto isakmp profile EZ match identity group EZ client authentication list EZ isakmp authorization list EZ client configuration address respond crypto ipsec transform-set ESP3DES esp-3des esp-sha-hmac crypto dynamic-map DYN 10 set transform-set ESP3DES set reverse-route tag 99 reverse-route crypto map VPN 10 ipsec-isakmp dynamic DYN interface FastEthernet0/1 ip address 8.9.6.6 255.255.255.0 crypto map VPN interface Serial0/1/0 ip address 8.9.56.6 255.255.255.0 crypto map VPN R6#sh crypto map Crypto Map "VPN" 10 ipsec-isakmp Dynamic map template tag: DYN Crypto Map "VPN" 65536 ipsec-isakmp Peer = 8.9.11.4 Extended IP access list access-list permit ip any host 20.0.0.7 dynamic (created from dynamic map DYN/10) Current peer: 8.9.11.4 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ ESP3DES, } Reverse Route Injection Enabled Crypto Map "VPN" 65537 ipsec-isakmp Peer = 8.9.6.10 Extended IP access list access-list permit ip any host 20.0.0.8 dynamic (created from dynamic map DYN/10) Current peer: 8.9.6.10 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ ESP3DES, } Reverse Route Injection Enabled Interfaces using crypto map VPN: FastEthernet0/1 Serial0/1/0 First session has the peer with the facing interface, second session with the non facing interface: R6#sh crypto session detail Interface: Serial0/1/0 Username: cisco Profile: EZ Group: EZ Assigned address: 20.0.0.7 Uptime: 00:03:19 Session status: UP-ACTIVE Peer: 8.9.11.4 port 500 fvrf: (none) ivrf: (none) Phase1_id: EZ Desc: (none) IKE SA: local 8.9.56.6/500 remote 8.9.11.4/500 Active Capabilities:CX connid:1007 lifetime:23:56:33 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 20.0.0.7 Active SAs: 2, origin: dynamic crypto map Inbound: #pkts dec'ed 5 drop 0 life (KB/Sec) 4489498/3400 Outbound: #pkts enc'ed 5 drop 0 life (KB/Sec) 4489498/3400 Interface: Serial0/1/0 Username: cisco Profile: EZ Group: EZ Assigned address: 20.0.0.8 Uptime: 00:01:57 Session status: UP-ACTIVE Peer: 8.9.6.10 port 7348 fvrf: (none) ivrf: (none) Phase1_id: EZ Desc: (none) IKE SA: local 8.9.56.6/500 remote 8.9.6.10/7348 Active Capabilities:CX connid:1008 lifetime:23:58:01 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 20.0.0.8 Active SAs: 2, origin: dynamic crypto map Inbound: #pkts dec'ed 4 drop 0 life (KB/Sec) 4503015/3482 Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4503016/3482 On Thu, Jun 21, 2012 at 9:07 PM, Eugene Pefti <eug...@koiossystems.com> wrote: Can you show the crypto maps applied to R6 interfaces? From: ccie_security-boun...@onlinestudylist.com [mailto:ccie_security-boun...@onlinestudylist.com] On Behalf Of Imre Oszkar Sent: Thursday, June 21, 2012 8:48 PM To: ccie security Subject: [OSL | CCIE_Security] dual armed EZVPN Hi guys, R4 (EZ remote) -----R6(EZ SERVER) ------ (EZ vpn client) The crypto map on R6 is applied to both interfaces (the one facing R4 and the one facing test pc) Both EzVPN clients are able to connect, however I noticed one interesting thing. The peer address on the clients must be the ip address of the facing interface otherwise the returning traffic from the server to the client will black holed by the server. The received packets are decrypted by the server but the returning traffic won't be encrypted. RIB/FIB are OK, they are pointing to the right interface/next-hop. Does anybody have an explanation why is this happening? Thanks! Oszkar _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
