cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8710
Views
0
Helpful
12
Replies

VPN site-to-site UP-ACTIVE but no traffic

fturato75
Level 1
Level 1

Hi guys,

i have to solve this situation please help me!!

I have 2 routers both cisco:

A) Cisco IOS Software, C1700 Software (C1700-ADVIPSERVICESK9-M), Version 12.4(15)T11, RELEASE SOFTWARE (fc2)

B) Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 15.1(4)M8, RELEASE SOFTWARE (fc2)

simple VPN IPSEC between 

My VPN tunnel is up and i have correct matches con access-list 110 but no ping, no traffic at all between hte 2 LANS.

In attach u can find both site A and B configurations , sh crypto session, sh crypto session detail, sh crypto isakmp sa, sh cryto ipsec sa

i really hope someone can help me .. i m getting fool !!

 

1 Accepted Solution

Accepted Solutions

What are the ip addresses 82.113.192.24 and 82.113.194.113? Are they hops down the dialer3 path? I guess not, as you would see the packets you initiated are being natted, and that would be the issue, the reason would be because they are going out another path "not via dialer3" or because the route map "NAT-DATI-ADSL2" is not working as it should.

I do still think the issue is related to the route path towards the BROKER-AREA, I think dialer3 is not being used when tunnel traffic is being initiated from areaCattolica.

I would set up a little lab today to test the route map you applied on dialer3 nat statement. We might need to start troubleshooting with some debugs, but before that I would test the route map then let you know.

Regards,

Aref

View solution in original post

12 Replies 12

Which IPs are you testing from/to?

At first glance the configuration looks fine, but I am a little curious as to why you have this command:

ip route 192.168.1.0 255.255.255.0 FastEthernet0.50

The default route will also send traffic out this interface given that Fa0.50 is assigned to dialer1

--

Please remember to select a correct answer and rate helpful posts

--
Please remember to select a correct answer and rate helpful posts

Hi Fturato,

First of all, I would like to ask you to post again the output of "sh cry is sa" on both ends, because in the attached files I noticed that on both ends the source and destination of the tunnel are the same, on areaCattolica the destination peer should be seen as 128.65.201.28 and the source as 128.65.207.6.

Now in regard to the communication issue between the two ends, I think that would be due to some routing issue, on router areaCattolica there is a default static route via dialer1, so the policy nat NAT-DATI-ADSL2 you applied would not be matched, because the traffic coming from network 192.168.1.0 towards any would not go through dialer3 interface of that default static route via dialer1, instead it would go through dialer1, so the nat statement would not be applied on dialer3 and the traffic coming from 192.168.1.0 network would be exiting (returning to AREA-BROKER) via dialer1 public ip so the other end would not receive it over the tunnel, in fact if you look at AREA-BROKER output, there are zero packet received over the tunnel, but there are some sent over it, instead on areaCattolica output, there are some packets received over the tunnel, but zero sent.

Please try one of these solutions:

On areaCattolica router:

Since the order of operation from inside to outside would hit the routing before natting, you would add a static route with a longest match towards the AREA-BROKER lan so it would be prefered over the default static route via dialer1.

ip route 192.168.1.0 255.255.255.0 Dialer3

Or

route-map PBR-VOCE permit 30
 match ip address 110
 set interface Dialer3

 

You should clear ip nat translations and the crypto isakmp before trying again to establish the tunnel between the two ends.


And as was mentioned by Marius, please remove the static route "ip route 192.168.1.0 255.255.255.0 f0.50" on AREA-BROKER even if that route would not be taken in consideration since the vlan50 interface has no ip address, so the route would not be installed in the routing table at the first place.

 

Regards,
Aref

first of all thank you very much for help...

but pity no solution worked

yeah the "192.168.1.0 255.255.255.0 f0.50" was only a test and now is cancelled 

my test are from 192.168.1.150 to 192.168.0.150

i added "ip route 192.168.1.0 255.255.255.0 Dialer3" on cattolica router nothing changed also after having cleared and re-established ipsec tunnel

and for what i could know the output of "sh cry isa sa" is right depends only on the connection establisher u can check isakmp conf in the running config and both are configured trought the correct peer.

Someone told me could be an MTU issue but i don't know how to debug or check it

i attach upgraded file and output

 

thanks again for any help

Please post the outputs of the following command issued on areaCattolica:

traceroute 192.168.0.150

sh ip route

 

Regards,

Aref

sure, 


areaCattolica#traceroute 192.168.0.150
Type escape sequence to abort.
Tracing the route to 192.168.0.150
VRF info: (vrf in name/id, vrf out name/id)
  1 82.113.192.24 24 msec 24 msec 24 msec
  2 82.113.194.113 28 msec 64 msec 24 msec
  3  *  *  *
  4  *  *  *
  5  *  *  *
  6  *  *  *
  7  *  *  *
  8  *  *  *
  9  *  *  *
 10  *  *  *
 11  *  *  *
 12  *  *  *
 13  *  *  *
 14  *  *  *
 15  *  *  *
 16  *  *  *
 17  *  *  *
 18  *  *  *
 19  *  *  *
 20  *  *  *
 21  *  *  *
 22  *  *  *
 23  *  *  *
 24  *  *  *
 25  *  *  *
 26  *  *  *
 27  *  *  *
 28  *  *  *
 29  *  *  *
 30  *  *  *

 

areaCattolica#show ip route
Codes: L - local, C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, Dialer1
      82.0.0.0/32 is subnetted, 2 subnets
C        82.113.192.19 is directly connected, Dialer2
                       is directly connected, Dialer1
C        82.113.192.24 is directly connected, Dialer3
      128.65.0.0/32 is subnetted, 3 subnets
C        128.65.206.243 is directly connected, Dialer1
C        128.65.206.247 is directly connected, Dialer2
C        128.65.207.6 is directly connected, Dialer3
S     192.168.0.0/24 is directly connected, Dialer3
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, FastEthernet0/0
L        192.168.1.254/32 is directly connected, FastEthernet0/0

 

Fturato, as I was doubting, the route map NAT-DATI-ADSL2 is not working properly. Assuming that you applied the "ip route 192.168.0.0 255.255.255.0 dialer3" which is needed to make it work, when you initiate traffic from the network 192.168.1.0/24 (areaCattolica) towards the network 192.168.0.0/24 (BROKER-AREA), the route map match ip address would prefer the match of the traffic from 192.168.1.0/24 towards 192.168.0.0/24 on access list 110 over 100, so what happens would be this, by prefering that match ace in access list 110 the nat would be applied to that traffic flow, because there is no deny statements on that access list, if while you are doing the traceroute you issue the command "sh ip nat translations" you would see that traffic is being natted, I think this preference in the matching would be relative to the longest match logic, since the access list 110 has a longest match over the access list 100 of the traffic sourcing from the network 192.168.1.0/24 towards 192.168.0.0/24 it would win.

Now the solution should be this:

On areaCattolica you should add a specific route towards the network 192.168.0.0/24 via dialer3 as mentioned in one of my previous posts, then you should remove the match of the access list 110 from the route map NAT-DATI-ADSL2.

ip route 192.168.0.0 255.255.255.0 dialer3

route-map NAT-DATI-ADSL2 permit 10
 no match ip address 100 110
 match ip address 100

Please remember to clear the tunnel and nat translations before trying again.

Regards,

Aref

Are you testing with ping?

If so, have you turned off the firewalls on the PCs (ie. windows firewall) when testing?  Or at least permitted ICMP in the software firewalls?

--

Please remember to select a correct answer and rate helpful posts

--
Please remember to select a correct answer and rate helpful posts

yep testing with ping . and no destination address is a PBX and i know he answer ping , no firewalls in the route.

What are the ip addresses 82.113.192.24 and 82.113.194.113? Are they hops down the dialer3 path? I guess not, as you would see the packets you initiated are being natted, and that would be the issue, the reason would be because they are going out another path "not via dialer3" or because the route map "NAT-DATI-ADSL2" is not working as it should.

I do still think the issue is related to the route path towards the BROKER-AREA, I think dialer3 is not being used when tunnel traffic is being initiated from areaCattolica.

I would set up a little lab today to test the route map you applied on dialer3 nat statement. We might need to start troubleshooting with some debugs, but before that I would test the route map then let you know.

Regards,

Aref

thank u very much for all the help .. nat was not working properly .. i deleted all nat entry and all nat configurations .. did a reload of the router .. then inserted nat route 1 by 1 matching access-list 100 instead of 110 and now its all working.

really thank u 

Glad we could fix it up, and you are very welcome.

Regards (Ciao amico)

Aref

From the log the traffic is one directional, so the ping packet should be arrived at the destination, in the reverse direction the ping response packet is NATed, so it would never reach its ping initiator.

To narrow down the issue, thus remove the nat configuration then try, if ok, then rewrite the nat related config.

Good luck,

 

David