Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Site to Site VPN Issue

Hello,

 

i am facing an issue in my site to site VPN configuration, the branch site Router is getting the Public IP Address from DHCP so i built a dynamic crypto MAP on the HQ router

 

ISAKMP phase one is up and running , i am trying to ping from the local network 192.168.85.0 to the HQ local network 172.16.12.0 but it doesn't go through and when i check the ipsec SAs i can see that the packets are encrypted on the branch side and decrypted on the HQ side but the HQ router doesn't reply the PING at all and there is no encrypted packets seen

 

i attached my configurations, i had to hide some information just for security

please help!!

 

Mostafa

2 ACCEPTED SOLUTIONS

Accepted Solutions
Silver

Hello Mustafa,

Hello Mustafa,

Havinf a look at your config, it seems that you have not configured NAT exemption correctly on your HQ.

ip access-list extended NAT
 deny   ip 172.16.12.0 0.0.0.255 192.168.75.0 0.0.0.255
 deny   ip 172.16.12.0 0.0.0.255 172.16.20.0 0.0.0.255
 permit ip 172.16.12.0 0.0.0.255 any
 deny   ip 172.16.12.0 0.0.0.255 192.168.85.0 0.0.0.255

In this ACL interesting traffic is denied in the last. Therefore this is not exempted from NAT, as ACL are processed top down, your interesting traffic is already matching permit statement in NAT ACL therefore subjected to NAT on HQ. Deny statement for NAT exemption of interesting traffic should be before permit statement.

HTH

"Please rate helpful posts"

Hi Mustafa,

Hi Mustafa,

As Poonam@ mentioned, you have problem in ACL on HQ config. please modify the NAT ACL as below:

ip access-list extended NAT
 deny   ip 172.16.12.0 0.0.0.255 192.168.75.0 0.0.0.255
 deny   ip 172.16.12.0 0.0.0.255 172.16.20.0 0.0.0.255
 deny   ip 172.16.12.0 0.0.0.255 192.168.85.0 0.0.0.255
 permit ip 172.16.12.0 0.0.0.255 any

hope this will work

regards,

kazim

14 REPLIES
New Member

HQ:crypto dynamic-map VPN-MAP

HQ:

crypto dynamic-map VPN-MAP 40
set security-association lifetime seconds 86400

New Member

i already tried this but

i already tried this but still not working, seems that the HQ router is not responding to the PING request , it is only decrypting the packets coming from the branch side

New Member

Did you also add the lifetime

Did you also add the lifetime with the branch?

Any counter increases on your VPN ACLs? 

I assume your VLANs are up and a node is connected on each side?

Why are you running x-auth on the branch and not the core? 

Why are you running reverse-route injection? 

New Member

-yes life time is added on

-yes life time is added on both sides

-sorry i dont know how to check the counter on ACL!

-i just have one subnet on the branch side for now ,  i dont need VLANs

-i dont want the branch router to go through user type authentication phase as it is the one establishing the connection not the HQ

-there is another router connected to the HQ router so i need the internal routes to be populate to the branch router subnet

New Member

On the branch "show ip access

On the branch "show ip access-list VPN-MIAMI" and see if the counters increment during pings.

On the HQ "show ip access-list OFFICE-BACKUP" and see if the counters increment during same pings.

What do you have plugged into the LAN port of the branch side? An L2 switch? 

Can you provide the output of "show ip int brief" from both sides?

New Member

show ip access-list OFFICE

show ip access-list OFFICE-BACKUP
Extended IP access list OFFICE-BACKUP
    10 permit ip 172.16.12.0 0.0.0.255 192.168.85.0 0.0.0.255 (165 matches)

 

 

ip access-lists VPN-MIAMI         
Extended IP access list VPN-MIAMI
    10 permit ip 192.168.85.0 0.0.0.255 172.16.12.0 0.0.0.255 (82 matches)

 

 

yes both increment

 

i have a laptop plugged into the LAN port and it takes a DHCP ip address from the pool

 

HQ:

MIAMI_R1#sh ip interface BRief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES manual up                    up      
GigabitEthernet0/0.1       172.16.12.3     YES manual up                    up      
GigabitEthernet0/0.2       69.42.108.228   YES manual up                    up      
GigabitEthernet0/1         unassigned      YES manual administratively down down    
GigabitEthernet0/2         192.168.0.1     YES manual up                    up      
NVI0                       unassigned      NO  unset  up                    up

 

Branch:

test#sh ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Embedded-Service-Engine0/0 unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/0         192.168.85.1    YES NVRAM  up                    up      
GigabitEthernet0/1         208.99.128.177  YES DHCP   up                    up      
GigabitEthernet0/2         unassigned      YES NVRAM  administratively down down    
NVI0                       unassigned      YES unset  administratively down down

 

New Member

I'm guessing you don't have

I'm guessing you don't have support / access to TAC?

Config looks fine, so likely an easier one to fix if someone can get on the devices and have a look for you.

New Member

 no i dont have access to the

 

no i dont have access to the cisco TAC

 

yes probably i will try to get someone to look at it

 

Thank you Adam for the support

 

Mostafa

New Member

No problem. I'd be happy to

No problem. I'd be happy to take a deeper look at it for you, if you don't have someone locally to do so. 

Silver

Hello Mustafa,

Hello Mustafa,

Havinf a look at your config, it seems that you have not configured NAT exemption correctly on your HQ.

ip access-list extended NAT
 deny   ip 172.16.12.0 0.0.0.255 192.168.75.0 0.0.0.255
 deny   ip 172.16.12.0 0.0.0.255 172.16.20.0 0.0.0.255
 permit ip 172.16.12.0 0.0.0.255 any
 deny   ip 172.16.12.0 0.0.0.255 192.168.85.0 0.0.0.255

In this ACL interesting traffic is denied in the last. Therefore this is not exempted from NAT, as ACL are processed top down, your interesting traffic is already matching permit statement in NAT ACL therefore subjected to NAT on HQ. Deny statement for NAT exemption of interesting traffic should be before permit statement.

HTH

"Please rate helpful posts"

New Member

Good catch! Can't believe I

Good catch! Can't believe I missed that. 

New Member

that did the trick, amazing

that did the trick, amazing

 

thank you very much for the help , i appreciate it

 

thanks everyone for the help.

 

Hi Mustafa,

Hi Mustafa,

As Poonam@ mentioned, you have problem in ACL on HQ config. please modify the NAT ACL as below:

ip access-list extended NAT
 deny   ip 172.16.12.0 0.0.0.255 192.168.75.0 0.0.0.255
 deny   ip 172.16.12.0 0.0.0.255 172.16.20.0 0.0.0.255
 deny   ip 172.16.12.0 0.0.0.255 192.168.85.0 0.0.0.255
 permit ip 172.16.12.0 0.0.0.255 any

hope this will work

regards,

kazim

New Member

yes exactly that worked like

yes exactly that worked like magic , thanks Kazim

141
Views
0
Helpful
14
Replies
CreatePlease to create content