Solved: Yes, I have.

terry.lowe · ‎12-23-2015

Hi all,

Note: Attached is the design setup and the VPN configurations.

Site-to-site VPN was configured on two 2811 routers (HQ-RTR & BRANCH-RTR). HQ-RTR has a public static IP address of 180.12.54.1, while BRANCH-RTR has a public dynamic IP of 10.93.7.25 via a ISP modem with its own configured LAN of 10.0.0.0/24.

Using "show crypto session", the tunnel between the two routers says that it is "UP-ACTIVE", however the LANs: 10.0.0.0/24 at Branch and 10.10.10.0/24 at HQ are unable to ping to one another.

Oddly enough, via "show crypto isakmp sa":

HQ-RTR results show dst= 180.12.54.1; src= 10.93.7.25 (i.e. Orange Tunnel)

(while BRANCH-RTR show: dst= 180.12.54.1; src= 10.0.0.2 (i.e. Green Tunnel)

Currently trying to solve this issue, as there is another setup to be configured: to allow LAN 10.10.50.0/24 to communicate with HQ Branch LAN 10.10.10.0/24. This LAN has already been configured to access the Internet.

Advice and suggestions are most welcome and appreciated.

Thanks.

Javaid Lillah · ‎12-29-2015

Hi Terry,

What is the purpose of these access-list 1 at HUB-RTR? Although there is correct deny statement configured in acl 115 however as this is over-lapping and acl 115 doesn't seems effective. I believe if you remove this VPN should work fine. Let me know the results.

ip nat inside source list 1 interface FastEthernet0/1 overload
access-list 1 permit 10.10.10.0 0.0.0.255

View solution in original post

Javaid Lillah · ‎12-23-2015

Hi Terry,

Can you please post the output of "show crypto session detail" on both routers.

Oddly enough, via "show crypto isakmp sa":

HQ-RTR results show dst= 180.12.54.1; src= 10.93.7.25 (i.e. Orange Tunnel)

(while BRANCH-RTR show: dst= 180.12.54.1; src= 10.0.0.2 (i.e. Green Tunnel)

This is correct behavior because device with public IP address 10.93.7.25 is natting the BRANCH-RTR wan interface IP 10.0.0.2. So in that case HQ-RTR will show the public IP address while the BRANCH-RTR will show its local interface IP address.

terry.lowe · ‎12-27-2015

Hi Javaid,

Thanks for getting back.

I have attached the screenshot outputs for the crypto session detail on both routers.

This is correct behavior because device with public IP address 10.93.7.25 is natting the BRANCH-RTR wan interface IP 10.0.0.2. So in that case HQ-RTR will show the public IP address while the BRANCH-RTR will show its local interface IP address.

Thanks for clarifying this. Good to know it is going at the right direction at least.

Javaid Lillah · ‎12-28-2015

It seems HUB-RTR is receiving encrypted traffic from branch router however it is not encrypting traffic for route 10.0.0.0/24 through the tunnel. This is not tunnel itself issue and usually caused by mis-configured NAT. For HUB-RTR, please post the running-config of NAT acl and NAT binding. Also send the running-config of LAN interface on which subnet 10.10.10.0/24 is configured.

terry.lowe · ‎12-29-2015

Hi Javaid,

The following running-config for NAT on both routers:

HUB-RTR

!
interface FastEthernet0/1

description *** TO INTERNET ***

ip address 180.12.54.1 255.255.255.252

ip nat outside
ip virtual-reassembly
duplex auto
speed auto
crypto map VPN
!

interface FastEthernet0/0

description ***TO SW***

ip address 10.10.10.1 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

!
ip route 0.0.0.0 0.0.0.0 180.12.54.1
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
!
ip nat inside source list 1 interface FastEthernet0/1 overload
ip nat inside source list 115 interface FastEthernet0/1 overload

!
ip access-list extended HQ-VPN
permit ip 10.10.10.0 0.0.0.255 10.0.0.0 0.0.0.255
ip access-list extended VPN-TO-BRANCH
permit ip 10.10.10.0 0.0.0.255 10.0.0.0 0.0.0.255
!
access-list 1 permit 10.10.10.0 0.0.0.255
access-list 115 deny ip 10.10.10.0 0.0.0.255 10.0.0.0 0.0.0.255
access-list 115 permit ip 10.10.10.0 0.0.0.255 any
!

REMOTE-RTR

interface FastEthernet0/1

ip address 10.0.0.2 255.255.255.0

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

crypto map VPN

!

interface FastEthernet0/0

ip address 10.10.50.1 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

!

ip nat inside source list 1 interface FastEthernet0/1 overload

ip nat inside source list 115 interface FastEthernet0/1 overload

!

ip access-list extended BRANCH-VPN

permit ip 10.0.0.0 0.0.0.255 10.10.10.0 0.0.0.255

!
ip route 0.0.0.0 0.0.0.0 10.0.0.1
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
!

access-list 1 permit 10.10.50.0 0.0.0.255

access-list 115 deny ip 10.0.0.0 0.0.0.255 10.0.0.0 0.0.0.255
access-list 115 permit ip 10.0.0.0 0.0.0.255 any
!

Javaid Lillah · ‎12-29-2015

Hi Terry,

What is the purpose of these access-list 1 at HUB-RTR? Although there is correct deny statement configured in acl 115 however as this is over-lapping and acl 115 doesn't seems effective. I believe if you remove this VPN should work fine. Let me know the results.

ip nat inside source list 1 interface FastEthernet0/1 overload
access-list 1 permit 10.10.10.0 0.0.0.255

terry.lowe · ‎12-30-2015

Hi Javaid,

Originally, before configuring VPN, access-list 1 was to simply allow subnet 10.10.10.0/24 access to Internet.

I have removed it as suggested, but unfortunately still encountering the same issue.

Javaid Lillah · ‎12-30-2015

Have you removed the both lines I mentioned above from config?

Also please send the output of 'show crypto session detail' on hub router.

terry.lowe · ‎12-30-2015

Yes, I have.

ip nat inside source list 1 interface FastEthernet0/1 overload
access-list 1 permit 10.10.10.0 0.0.0.255

I attempted ping to create the output for crypto session, and to my surprise it seemed to have worked for a brief moment:

Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!.!

However, after saving the configurations, it stopped working again. Could it possibly be an ISP issue on the remote end?

Crypto session detail for hub:

Interface: FastEthernet0/1
Session status: UP-ACTIVE
Peer: 10.93.7.25 port 6002 fvrf: (none) ivrf: (none)
Phase1_id: 10.0.0.2
Desc: (none)
IKE SA: local 180.12.54.1/4500 remote 10.93.7.25/6002 Active
Capabilities:N connid:1 lifetime:23:40:24
IPSEC FLOW: permit ip 10.10.10.0/255.255.255.0 10.0.0.0/255.255.255.0
Active SAs: 2, origin: dynamic crypto map
Inbound: #pkts dec'ed 288 drop 0 life (KB/Sec) 4575513/2494
Outbound: #pkts enc'ed 548 drop 0 life (KB/Sec) 4575468/2494

Javaid Lillah · ‎12-30-2015

Perfect, it is showing traffic both ways now. ISP shouldn't be an issue as long as internet is working fine at both ends.

Please retry pinging with the source IP given or generate traffic from the host. Let me know results.

terry.lowe · ‎12-30-2015

Yes. Thank you, Javaid. It seems to be working.

There is often packet losses, probably due to high latency on remote site, which is >1000ms even when accessing the Internet.

HUB-RTR#ping 10.0.0.2 source 10.10.10.1 repeat 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
....!!!.!.!!...!.!!.!.!!..!!..!.!!!.!.!.......!...
Success rate is 42 percent (21/50), round-trip min/avg/max = 1404/1694/1996 ms

RMTE-V_RTR#ping 10.10.10.1 source 10.0.0.2 repeat 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.2
...!.!.!.!.!...!..!..!!!....!!.!.!........!...!...
Success rate is 32 percent (16/50), round-trip min/avg/max = 1200/1638/1936 ms
RMTE-V_RTRr#ping www.google.com rep 50

Translating "www.google.com"...domain server (10.0.0.1) [OK]

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 74.125.237.20, timeout is 2 seconds:
........................!...........!.!.......!...
Success rate is 8 percent (4/50), round-trip min/avg/max = 1368/1558/1820 ms

Site-to-Site VPN (LANs unable to communicate)