asked on
IPSec VPN Tunnel Not Injecting Addressing
Hello Community,
I have created an VPN as shown in the attached configs. The tunnel is up and ipsec appears to working fine. However, I'm unable to ping the address 10.1.0.4 (interface on the router) from the other site with address 10.12.0.4. I think the problem might be that traffic isn't being recognized in the ipsec tunnel as shown here:
cisco-csr-vpn#show crypto ipsec sa
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 10.1.0.4
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 52.184.181.0 port 4500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 80, #pkts encrypt: 80, #pkts digest: 80
#pkts decaps: 83, #pkts decrypt: 83, #pkts verify: 83
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.1.0.4, remote crypto endpt.: 52.184.181.0
plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0xEC0058AA(3959445674)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xE8D52690(3906283152)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2002, flow_id: CSR:2, sibling_flags FFFFFFFF80000048, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4607992/3051)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEC0058AA(3959445674)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2001, flow_id: CSR:1, sibling_flags FFFFFFFF80000048, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4607996/3051)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
However, I'm not sure how to inject traffic into the tunnel. Can someone let me know where I might be going wrong?
Cheers
Carlton
14-40-46--52.225.134.147-52.225.134..txt
I have created an VPN as shown in the attached configs. The tunnel is up and ipsec appears to working fine. However, I'm unable to ping the address 10.1.0.4 (interface on the router) from the other site with address 10.12.0.4. I think the problem might be that traffic isn't being recognized in the ipsec tunnel as shown here:
cisco-csr-vpn#show crypto ipsec sa
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 10.1.0.4
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 52.184.181.0 port 4500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 80, #pkts encrypt: 80, #pkts digest: 80
#pkts decaps: 83, #pkts decrypt: 83, #pkts verify: 83
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.1.0.4, remote crypto endpt.: 52.184.181.0
plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
current outbound spi: 0xEC0058AA(3959445674)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xE8D52690(3906283152)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2002, flow_id: CSR:2, sibling_flags FFFFFFFF80000048, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4607992/3051)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEC0058AA(3959445674)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2001, flow_id: CSR:1, sibling_flags FFFFFFFF80000048, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4607996/3051)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
However, I'm not sure how to inject traffic into the tunnel. Can someone let me know where I might be going wrong?
Cheers
Carlton
14-40-46--52.225.134.147-52.225.134..txt
Internet Protocol SecurityVPN
Last Comment
Member_2_7966113
ASKER
Hi Predrag,
Thats a great answer. However, I thought I was advertising my local routes into BGP with the following BGP configuration?
router bgp 65051
bgp log-neighbor-changes
neighbor 10.12.255.30 remote-as 65515
neighbor 10.12.255.30 ebgp-multihop 255
!
address-family ipv4
network 10.1.0.0 mask 255.255.255.0
neighbor 10.12.255.30 activate
exit-address-family
!
!
Thats a great answer. However, I thought I was advertising my local routes into BGP with the following BGP configuration?
router bgp 65051
bgp log-neighbor-changes
neighbor 10.12.255.30 remote-as 65515
neighbor 10.12.255.30 ebgp-multihop 255
!
address-family ipv4
network 10.1.0.0 mask 255.255.255.0
neighbor 10.12.255.30 activate
exit-address-family
!
!
Oh, you are. :)
Sorry, my bad.
Check source ip address to hosts that access Azure server and are those routes in routing table of Azure router?
Try to ping interface Gi0/1 from Azure.
Sorry, my bad.
Check source ip address to hosts that access Azure server and are those routes in routing table of Azure router?
Try to ping interface Gi0/1 from Azure.
I totally forgot what was the point. :)
Are hosts that are trying to access part of 10.1.0.0/24 network or some other network? For me it does not mean that you are accessing from that network. Network 10.1.0.0/24 may be transit network.
Are hosts that are trying to access part of 10.1.0.0/24 network or some other network? For me it does not mean that you are accessing from that network. Network 10.1.0.0/24 may be transit network.
ASKER
Hi Predrag,
The address that I'm trying to ping (10.1.0.4) is the interface address of the router (see original attachment with configs). I'm trying to ping that address from a PC in Azure with address 10.12.0.4
Regards
The address that I'm trying to ping (10.1.0.4) is the interface address of the router (see original attachment with configs). I'm trying to ping that address from a PC in Azure with address 10.12.0.4
Regards
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Hi Predrag,
I just added the statics as you suggested, but no luck. I think I will need to get in touch with the Azure team
I just added the statics as you suggested, but no luck. I think I will need to get in touch with the Azure team
So, most likely, problem should be on Azure side. I guess you need to add some routes there.
You can leave static routes on Cisco side as long as you are testing (if you are certain about network IP address range). :)
You can't find better and more reliable routes than those. :)
When all is OK remove those routes and test with BGP routes only.
You can leave static routes on Cisco side as long as you are testing (if you are certain about network IP address range). :)
You can't find better and more reliable routes than those. :)
When all is OK remove those routes and test with BGP routes only.
ASKER
Thanks Predrag.
I have opened a support ticket with the Azure team.
I will keep you posted.
Regards
I have opened a support ticket with the Azure team.
I will keep you posted.
Regards
ASKER
Cheers
ip route 10.12.255.0 255.255.255.224 Tunnel1 (10.12.255.30 is included in this range)
should be good enough. However you are not advertising any routes into BGP from Cisco router, so I guess problem is return traffic.
And
r> 10.1.0.4/32 10.12.255.30 0 65515 i
you are advertising from Azure router your local Cisco route? That is in conflict with local route
C 10.1.0.0/24 is directly connected, GigabitEthernet1
L 10.1.0.4/32 is directly connected, GigabitEthernet1
That falls into category - you can't do that (you can, but it is pointless). :) This side need to advertise local route (other side should not have network with the same IP address range).
10.1.0.0/24 is directly connected, GigabitEthernet1
You need to advertise your source IP address network(s) into BGP so traffic can find way back (your source IP addresses must be advertised through BGP to Azure router so icmp-reply can find way back). If source network is not directly attached you will need to create static route and redistribute it into BGP.