03-03-2011 12:14 PM - edited 02-21-2020 05:12 PM
.........................................
Any ideas? ACL changes?THANKS SO MUCH! =)- Aaron.03-03-2011 05:17 PM
Here is a few suggestions:
#1: on the router, you need to add this command:
crypto map local-address interface lo0
#2: you also need to add this command to the interface Serial0/0/0:1
crypto map NOLA
#3: modify your access-list 101:
access-list 101 deny ip 10.240.4.0 0.0.3.255 10.32.244.0 0.0.3.255
access-list 101 deny ip 10.240.4.0 0.0.3.255 10.32.248.0 0.0.3.255
access-list 101 deny ip 10.240.8.0 0.0.3.255 10.32.244.0 0.0.3.255
access-list 101 deny ip 10.240.8.0 0.0.3.255 10.32.248.0 0.0.3.255
access-list 101 deny ip 10.240.4.0 0.0.3.255 host 10.6.4.56
access-list 101 deny ip 10.240.4.0 0.0.3.255 host 10.6.4.57
access-list 101 deny ip 10.240.8.0 0.0.3.255 host 10.6.4.56
access-list 101 deny ip 10.240.8.0 0.0.3.255 host 10.6.4.57
access-list 101 permit ip any any
That should work. Give that a try
03-03-2011 09:13 PM
Changed:
"crypto map NOLA local-address Loopback0"
"int Serial0/0/0:1
crypto map NOLA"
"route-map NO_NAT permit 10
match ip address NONAT-ACL"
mapped route-map NOLA (matching ip access-list NONAT-ACL) to Serial0/0/0:1:
"ip nat inside source route-map NO_NAT interface Serial0/0/0:1 overload"
New Router Config Below:
version 12.4
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key xxxxx address nn.nn.12.130
crypto ipsec security-association lifetime seconds 86400
crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac
!
crypto map NOLA local-address Loopback0
crypto map NOLA 11 ipsec-isakmp
set peer 24.248.12.130
set transform-set 3DES-SHA
match address VPN-ACL
!
interface Loopback0
ip address 1.1.1.1 255.255.255.252
ip virtual-reassembly
no ip route-cache
crypto map NOLA
!
interface Serial0/0/0:1
bandwidth 1536
ip address 12.249.236.6 255.255.255.252
no ip redirects
no ip unreachables
ip nat outside
ip virtual-reassembly
encapsulation ppp
no fair-queue
no cdp enable
crypto map NOLA
!
ip route 0.0.0.0 0.0.0.0 12.249.236.5
!
ip nat inside source route-map NO_NAT interface Serial0/0/0:1 overload
ip nat inside source static 1.1.1.1 12.203.244.210
!
ip access-list extended NONAT-ACL
deny ip 10.240.4.0 0.0.3.255 10.32.244.0 0.0.3.255
deny ip 10.240.4.0 0.0.3.255 10.32.248.0 0.0.3.255
deny ip 10.240.8.0 0.0.3.255 10.32.244.0 0.0.3.255
deny ip 10.240.8.0 0.0.3.255 10.32.248.0 0.0.3.255
deny ip 10.240.4.0 0.0.3.255 host 10.6.4.56
deny ip 10.240.4.0 0.0.3.255 host 10.6.4.57
deny ip 10.240.8.0 0.0.3.255 host 10.6.4.56
deny ip 10.240.8.0 0.0.3.255 host 10.6.4.57
permit ip any any
ip access-list extended VPN-ACL
permit ip 10.240.4.0 0.0.3.255 10.32.244.0 0.0.3.255
permit ip 10.240.4.0 0.0.3.255 10.32.248.0 0.0.3.255
permit ip 10.240.8.0 0.0.3.255 10.32.244.0 0.0.3.255
permit ip 10.240.8.0 0.0.3.255 10.32.248.0 0.0.3.255
permit ip 10.240.4.0 0.0.3.255 host 10.6.4.56
permit ip 10.240.4.0 0.0.3.255 host 10.6.4.57
permit ip 10.240.8.0 0.0.3.255 host 10.6.4.56
permit ip 10.240.8.0 0.0.3.255 host 10.6.4.57
!
route-map NO_NAT permit 10
match ip address NONAT-ACL
!
end
.......
Results are the same so far. Tunnel comes up upon "interesting traffic" from the ASA side. No pings are returned from either side.
Any ideas for further changes? =)
Thanks again!
03-04-2011 04:22 AM
Looking at your configuration on the router a little more, I think you need to do this:
access-list 101 deny ip 10.240.4.0 0.0.3.255 10.32.244.0 0.0.3.255
access-list 101 deny ip 10.240.4.0 0.0.3.255 10.32.248.0 0.0.3.255
access-list 101 deny ip 10.240.8.0 0.0.3.255 10.32.244.0 0.0.3.255
access-list 101 deny ip 10.240.8.0 0.0.3.255 10.32.248.0 0.0.3.255
access-list 101 deny ip 10.240.4.0 0.0.3.255 host 10.6.4.56
access-list 101 deny ip 10.240.4.0 0.0.3.255 host 10.6.4.57
access-list 101 deny ip 10.240.8.0 0.0.3.255 host 10.6.4.56
access-list 101 deny ip 10.240.8.0 0.0.3.255 host 10.6.4.57
access-list 101 permit ip 10.240.4.0 0.0.3.255 any
access-list 101 permit ip 10.240.4.0 0.0.3.255 any
access-list 101 permit ip 10.240.8.0 0.0.3.255 any
access-list 101 permit ip 10.240.8.0 0.0.3.255 any
access-list 101 permit ip 10.240.4.0 0.0.3.255 any
access-list 101 permit ip 10.240.4.0 0.0.3.255 any
access-list 101 permit ip 10.240.8.0 0.0.3.255 any
access-list 101 permit ip 10.240.8.0 0.0.3.255 any
The "permit ip any any" will do something strange to NAT.
03-04-2011 09:55 AM
I feel like we are getting there, but not yet...
Since I had been using the NONAT-ACL list (then mapped to the NO_NAT route-map) for the "ip nat inside source route-map NO_NAT int s0/0/0:1 overload" statement, I changed that list.
I ran:
ip access-list ext NONAT-ACL
no deny ip 10.240.4.0 0.0.3.255 10.32.244.0 0.0.3.255
no deny ip 10.240.4.0 0.0.3.255 10.32.248.0 0.0.3.255
no deny ip 10.240.8.0 0.0.3.255 10.32.244.0 0.0.3.255
no deny ip 10.240.8.0 0.0.3.255 10.32.248.0 0.0.3.255
no deny ip 10.240.4.0 0.0.3.255 host 10.6.4.56
no deny ip 10.240.4.0 0.0.3.255 host 10.6.4.57
no deny ip 10.240.8.0 0.0.3.255 host 10.6.4.56
no deny ip 10.240.8.0 0.0.3.255 host 10.6.4.57
no permit ip any any
deny ip 10.240.4.0 0.0.3.255 10.32.244.0 0.0.3.255
deny ip 10.240.4.0 0.0.3.255 10.32.248.0 0.0.3.255
deny ip 10.240.8.0 0.0.3.255 10.32.244.0 0.0.3.255
deny ip 10.240.8.0 0.0.3.255 10.32.248.0 0.0.3.255
deny ip 10.240.4.0 0.0.3.255 host 10.6.4.56
deny ip 10.240.4.0 0.0.3.255 host 10.6.4.57
deny ip 10.240.8.0 0.0.3.255 host 10.6.4.56
deny ip 10.240.8.0 0.0.3.255 host 10.6.4.57
permit ip 10.240.4.0 0.0.3.255 any
permit ip 10.240.8.0 0.0.3.255 any
Internet access is still functional, the tunnel was brought down and back up successfully, and the VPN-ACL list and NONAT-ACL list are definitely getting hits... but still no pings across from either side.
03-04-2011 10:34 AM
Is the problem Just with ICMP, can you check if the actual tcp/udp connections are working using the tunnel.
Please paste output of :-
sh service-policy | inc icmp
also just for the sake of it issue asa(config)# fixup protocol icmp
Manish
03-04-2011 10:45 AM
Manish,
On the ASA, ran "fixup protocol icmp", which then results in icmp being shown when I run "sh service-policy | i icmp". Result is: "Inspect: icmp, packet 668, drop 0, reset-drop 0".
There is no communication across, as far as I can tell. I have tried communication across ports 80, 443, and 3389, with no success.
- Aaron.
03-04-2011 10:53 AM
Since I am a little late on this thread, can you please attach the config of both sides as many changes have been done on it ? please attach rather then pasting , i will need notepad help to compare them . Please change public ip like 98.25.45.46 = 98.X.X.46 and remove any passwords.
Manish
03-04-2011 12:13 PM
03-04-2011 08:58 PM
Hi Aaron,
I just got time to review your configuration, I do see some issues with it on the router side :-
1> what is the reason of using loopback interface as tunnel endpoint and that too natted ( maybe for hardware acce as some devices need them ) , even if you have to use a loopback , can you use a public ip rather then natting something like 1.1.1.1 ?
2> The current configuration doesn't even show the static nat for loopback ? but your first post does show me a static nat ? so please verify.
3> another thing I would want to see is the "sh ip route" from the router ?
Manish
03-05-2011 06:12 AM
Looking at your configuration a little bit more, I don't think it will work because:
1- yes, phase I in the ISAKMP will come up:
13:32:41.480194 129.174.1.13.500 > 164.109.1.8.500: isakmp: phase 1 I ident [tos 0xc0]
13:32:41.592441 164.109.1.8.500 > 129.174.1.13.500: isakmp: phase 1 R ident [tos 0xc0]
13:32:42.118383 129.174.1.13.500 > 164.109.1.8.500: isakmp: phase 1 I ident [tos 0xc0]
13:32:42.261988 164.109.1.8.500 > 129.174.1.13.500: isakmp: phase 1 R ident [tos 0xc0]
13:32:44.263966 129.174.1.13.500 > 164.109.1.8.500: isakmp: phase 1 I ident[E] [tos 0xc0]
13:32:44.463999 164.109.1.8.500 > 129.174.1.13.500: isakmp: phase 1 R ident[E] [tos 0xc0]
13:32:46.309855 129.174.1.13.500 > 164.109.1.8.500: isakmp: phase 2/others I oakley-quick[E] [tos 0xc0]
13:32:46.566081 164.109.1.8.500 > 129.174.1.13.500: isakmp: phase 2/others R oakley-quick[E] [tos 0xc0]
13:32:47.254981 129.174.1.13.500 > 164.109.1.8.500: isakmp: phase 2/others I oakley-quick[E] [tos 0xc0]
2- However, in the Phase II where the ESP will take place, that's when you will run into issue because:
13:32:47.805637 1.1.1.1 > 164.109.1.8: ESP(spi=0x758f6ca5,seq=0x1) --- outbound
13:32:47.806990 164.109.1.8 > 129.174.1.13: ESP(spi=0x721a31a5,seq=0x1)
13:32:47.814603 1.1.1.1 > 164.109.1.8: ESP(spi=0x758f6ca5,seq=0x2) --- outbound
13:32:47.815734 164.109.1.8 > 129.174.1.13: ESP(spi=0x721a31a5,seq=0x2)
13:32:51.379740 1.1.1.1 > 164.109.1.8: ESP(spi=0x758f6ca5,seq=0x3) -- outbound
13:32:51.381074 164.109.1.8 > 129.174.1.13: ESP(spi=0x721a31a5,seq=0x3)
As you can see in the ESP phase, where your ping actually happens, that traffics is encrypted with the 1.1.1.1 (loopback ip address)
and this is the address that for ESP traffics between the router and the ASA. And because of this, it will break your phase II, as you can see
in the tcpdump on a device upstream from the router that terminate IPSec
Therefore, I would assume with your existing configuration, it will not work because IPSec will not translate 1.1.1.1 to 129.174.1.13 on the outbound ESP, as seen in the above example.
03-05-2011 06:05 PM
Manish and cciesec2011,
Thanks for sticking with me so far. I have tied the Loopback0 interface directly to the peer address for the IPSec tunnel.
no ip nat inside source static 1.1.1.1 nn.nn.244.210
interface Loopback0
ip address nn.nn.244.210 255.255.255.248
The tunnel came back up OK when initiated, but traffic still does not pass through.
- Aaron.
03-06-2011 09:49 AM
Aaron,
Can you please post the show ip route from the router ?
Manish
Sent from Cisco Technical Support iPhone App
03-06-2011 10:23 AM
Add the following routes to the router and it will work after that:
ip route 10.32.244.0 255.255.252.0 nn.nn.244.210
ip route 10.32.248.0 255.255.252.0 nn.nn.244.210
ip route 10.6.4.56 255.255.255.255 nn.nn.244.210
ip route 10.6.4.57 255.255.252.255 nn.nn.244.210
it will work after that. As a rule of thumb, in Cisco, routing will take place before encryption kicks in.
03-07-2011 07:28 AM
Manish and cciesec2011,
The ip route statements on the router is currently:
ip route 0.0.0.0 0.0.0.0 Serial0/0/0:1
ip nat inside source route-map NO_NAT interface Serial0/0/0:1 overload
The result of "sh ip route" is:
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C 10.240.6.128/25 is directly connected, GigabitEthernet0/1.21
C 10.240.8.0/22 is directly connected, GigabitEthernet0/1.40
C 10.240.6.0/25 is directly connected, GigabitEthernet0/1.20
C 10.240.4.0/24 is directly connected, GigabitEthernet0/1.1
C 10.240.5.0/24 is directly connected, GigabitEthernet0/1.10
12.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C nn.nn.236.5/32 is directly connected, Serial0/0/0:1
C nn.nn.236.4/30 is directly connected, Serial0/0/0:1
C nn.nn.244.208/29 is directly connected, Loopback0
S* 0.0.0.0/0 is directly connected, Serial0/0/0:1
Running the commands: ip route 10.32.244.0 255.255.252.0 nn.nn.244.210, etc., resulted in the following error each time:
%Invalid next hop address (it's this router)
Any ideas? Should the subnets be routed out of the Loopback0 interface directly?
Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide