08-02-2024 01:51 PM - edited 08-03-2024 09:42 AM
Hi,
I recently set up a site-to-site IPsec VPN tunnel with a customer, and soon after informed me that they use the same subnet for their VPN Peer IP address and the LAN behind it. They can't do NATing at the moment. They've even planned for some of our LAN traffic to communicate directly with their peer IP. I have never seen a VPN with the same IP addressing scenario, so I'm not sure whether this set up will work or not. I have tried to search online but with no succuss.
The VPN tunnel is up, and we have set it up as a route-based tunnel using tunnel mode for the IPsec transform-set. Can anyone provide insights or confirmation on whether this configuration will work?
BTW my router is a has many VPN peers, and I have myself set up many VPN tunnels. My question is not about configuring a VPN tunnel but the fact that the remote peer and remote LAN are in the same subnet.
Site A (My side):
Peer IP: 10.10.10.1 , LAN 10.10.0.0/24 (different subnet)
Site B (Customer_X):
Peer IP 20.20.20.55, LAN 20.20.20.0/24 ==> here's the issue (same subnet)
Problem: Customer's VPN Peer IP is in the same subnet as their LAN
Current config:
----------------
interface Tunnel5
vrf forwarding Customer_X
ip address 169.254.0.5 255.255.255.255
ip tcp adjust-mss 1350
tunnel source 10.10.10.1
tunnel mode ipsec ipv4
tunnel destination 20.20.20.55
tunnel vrf frontdoor
tunnel protection ipsec profile ipsec-profile
!
interface GigabitEthernet0/5
description ***out to the internet***
vrf forwarding frontdoor
ip address 10.10.10.1 255.255.255.248
ip tcp adjust-mss 1360
!
ip route vrf Customer_X 20.20.20.0 255.255.255.0 Tunnel5
!
Solved! Go to Solution.
08-03-2024 11:01 AM
@Ab26 by the looks of your output, that is not a VTI? As the local/remote ident would be 0.0.0.0/0.0.0.0/0/0.
Router#sh crypto ipsec sa peer 20.20.20.55
interface: Tunnel5
Crypto map tag: Tunnel5-head-0, local addr 10.10.10.1
protected vrf: Customer_X
local ident (addr/mask/prot/port): (10.10.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (20.20.20.0/255.255.255.0/0/0)
current_peer 20.20.20.55 port 500
PERMIT, flags={}
#pkts encaps: 16, #pkts encrypt: 16, #pkts digest: 16
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
....but you also have the following, there are no ESP inbound|outbound SA established.
protected vrf: Customer_X
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 20.20.20.55 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#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 10, #recv errors 0
local crypto endpt.: 10.10.10.1, remote crypto endpt.: 20.20.20.55
plaintext mtu 9216, path mtu 9216, ip mtu 9216, ip mtu idb GigabitEthernet0/5
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
Router#
I can also see that there are encaps but no decaps, which usually indicates an issue on the remote side not returning the traffic, either a routing or NAT issue.
08-03-2024 11:19 AM
I saw the no decaps and I assumed the VPN is not configured correctly from the remote side. As for if there's a NATing, I usually run a debug for phase 1 and phase 2 to make sure that the parameters are set correctly on the remote side, and for this tunnel I didn't see any NATing.
Regarding the VTI part you mentioned, I'm sure that on my side I've only configured route-based VPN. Can this be an indication that the remote peer is configured as a Policy-based VPN?
Are there messages in any debug that help to identify a mismatch of the configured VPN type (route/policy) on each peer side?
08-03-2024 11:00 AM
Thanks a million @Rob Ingram !
Then I guess i don't need to modify any config from my side
08-03-2024 11:11 AM
I think it issue from your side.
You run ikev2 not ikev1' please confirm if you need form me run lab to check your issue.
I can run lab later today or max tomorrow
MHM
08-03-2024 11:18 AM
@MHM Cisco World IKEV2 works fine, any reason why you think it would not?
08-03-2024 11:29 AM
You lab use ikev1 or ikev2?
MHM
08-03-2024 11:22 AM
I use IKev2.
Rob has thankfully tested the VPN and confirmed it works. I have to troubleshoot with my customer, how they have configured the VPN on their end.
Thanks MHM !
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