10-31-2022 07:20 AM
Good morning!
I am setting up an IKEv2 IPSEC tunnel between my Cisco 881 and another company (They are using Oracle). We have the tunnel up and ready to go, but I cannot pass traffic through the tunnel. When I ping the public address for the other company, the pings complete, but they are going through the tunnel. I need to see what needs to be added (or deleted) in order to have traffic flow through the tunnel.
My Cisco 881 is connected to our Cisco 6513, which is our Layer 3 switch.
10-31-2022 07:26 AM
tunnel dont have IP so it down/down
and hence the traffic not go through tunnel
10-31-2022 07:47 AM
The Oracle documentation states that we do not need an IP on the Tunnel port, since their end does not have one. The tunnel port is currently up.
Tantalus#sho ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet4 unassigned YES NVRAM up up
FastEthernet4.2 10.1.1.72 YES NVRAM up up
FastEthernet4.89 198.37.29.62 YES NVRAM up up
Tunnel0 unassigned YES unset up up
10-31-2022 07:55 AM - edited 10-31-2022 08:07 AM
Tunnel is UP/UP because the destination is reachable but
cisco mandatory need IP for tunnel since here the VPN is route-based not policy-based VPN
also you need
static route <remote LAN> tunnel x
this force the traffic to pass through tunnel.
NOTE:- you can use LO (loopback) and use tunnel IP unnumbered from LO IP.
10-31-2022 01:04 PM
Thank you for the response. I added an IP to the tunnel:
interface Tunnel0
ip address 172.18.22.30 255.255.255.252
tunnel source FastEthernet4.89
tunnel mode ipsec ipv4
tunnel destination 129.213.169.148
tunnel protection ipsec profile TANTALUS_PROFILE
The end user added 172.18.22.29 255.255.255.252. I also added a static to their LAN address:
ip route 10.102.13.0 255.255.255.240 Tunnel0
I still cannot complete pings. I see the pings are going through the tunnel, but not coming back:
Crypto map tag: Tunnel0-head-0, local addr 198.37.29.62
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 129.213.169.148 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 36, #pkts encrypt: 36, #pkts digest: 36
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#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.: 198.37.29.62, remote crypto endpt.: 129.213.169.148
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4.89
current outbound spi: 0x256518EE(627382510)
PFS (Y/N): Y, DH group: group5
inbound esp sas:
spi: 0xB81E5B8F(3088997263)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 7, flow_id: Onboard VPN:7, sibling_flags 80000040, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4333020/3264)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x256518EE(627382510)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 8, flow_id: Onboard VPN:8, sibling_flags 80000040, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4333020/3264)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
11-01-2022 03:12 AM
the traffic use udp 500
""current_peer 129.213.169.148 port 500""
but the ACL IN in source interface not allow this port.
interface FastEthernet4.89 description TantalusPublic encapsulation dot1Q 89 ip address xxx.xxx.xxx.62 255.255.255.252 ip access-group TANTALUS-ACL in no ip redirects ip nat outside ip virtual-reassembly in
11-01-2022 06:28 AM
I thought that the permit line in the extended ACL ( permit udp host 129.213.169.148 host 198.37.29.62 eq isakmp) opened the port for use.
11-01-2022 06:42 AM - edited 11-01-2022 06:43 AM
can you check remove the ACL and do ping again, if OK
UDP (4500) sometime use if one Peer is behind NAT device.
11-01-2022 07:27 AM
I removed the ACL from the source port. Still having same issue. Pings are going out but not coming back
11-01-2022 07:59 AM
check other side do have route toward your router?
11-08-2022 06:15 AM
So we fixed the issue. I had to add static routes in my core siwtch and my router.
Router: ip route 172.22.2.0 255.255.255.0 108.59.209.3 (Core)
Core: ip route 10.102.13.0 255.255.255.240 198.37.29.62 (public interface on router)
We can ping across the tunnel and they can see our equipment as well!
The last piece of this puzzle missing is that we should be able to access their web GUI at http://10.102.13.6 since we can ping it, but we cannot. We are timing out.
11-08-2022 08:11 AM
Resolved the issue. Added permit tcp any any eq www to the extended ACL. That allowed the access we needed.
Thank you for all of your help!
11-08-2022 10:08 AM
Great and Fast Job friend,
glad your issue solved.
good luck.
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