ā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 10:55 AM
@Ab26 I tested your scenario and it will work with a route based VPN.
Example:
interface Tunnel1
vrf forwarding CUSTOMER-X
ip address 172.21.1.1 255.255.255.255
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 2.2.2.1
tunnel vrf FRONTDOOR
tunnel protection ipsec profile IPSEC-PROFILE
!
interface Loopback10
vrf forwarding CUSTOMER-X
ip address 10.10.0.1 255.255.255.255
!
ip route vrf FRONTDOOR 0.0.0.0 0.0.0.0 1.1.1.254
ip route vrf CUSTOMER-X 2.2.2.0 255.255.255.0 Tunnel1
R1#ping vrf CUSTOMER-X 2.2.2.3 source lo10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.3, timeout is 2 seconds:
Packet sent with a source address of 10.10.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/38 ms
R1#
*Aug 3 17:37:41.587: ICMP: echo reply rcvd, src 2.2.2.3, dst 10.10.0.1, topology BASE, dscp 0 topoid 2
From the remote peer side
interface Loopback0
vrf forwarding LAN
ip address 2.2.2.3 255.255.255.255
!
R2#show run | i route
ip route vrf LAN 10.0.0.0 255.0.0.0 Tunnel1
R2# debug ip icmp
*Aug 3 17:37:43.199: ICMP: echo reply sent, src 2.2.2.3, dst 10.10.0.1, topology BASE, dscp 0 topoid 1
*Aug 3 17:37:43.218: ICMP: echo reply sent, src 2.2.2.3, dst 10.10.0.1, topology BASE, dscp 0 topoid 1
R2#show crypto ipsec sa | i encaps|decaps
#pkts encaps: 122, #pkts encrypt: 122, #pkts digest: 122
#pkts decaps: 134, #pkts decrypt: 134, #pkts verify: 134
ā08-02-2024 02:10 PM
Do you use ASA FW?
MHM
ā08-02-2024 02:12 PM
Thanks for your reply! from our end we use a Cisco router
ā08-03-2024 04:49 AM
if you have router then you have two option to solve this issue
1- use route-base VPN and NATing your LAN to tunnel IP, this make other side not see your LAN and hence there is no overlapping
2- use policy-based VPN this need add LO and do NAT to this LO and use LO IP in ACL of VPN
regarding option 2 the router must support command "ip nat enable" if the router not support this command you can not config this hairpin NATing
MHM
ā08-03-2024 05:32 AM
Thanks for your suggestion @MHM Cisco World !
I guess in this case, the NATing is be done on the Customer side, Site-B?
Would you please elaborate a bit more about use of Lo in the Policy-based VPN?
Site A:
Peer IP: 10.10.10.1 , LAN 10.10.0.0/24
Site B (Customer_X):
Peer IP 20.20.20.55, LAN 20.20.20.0/24 ==> here's the issue (same subnet)
!
crypto map VPN_L2L 5 ipsec-isakmp
set peer 20.20.20.55
set transform-set IPsec_Transform_Set
set ikev2-profile IKev_Profile
match address ACL_VPN
reverse-route remote-peer 10.10.10.3 static
!
ip route vrf Customer_X 10.10.10.3 255.255.255.255 GigabitEthernet0/5 10.10.10.3
!
ip access-list extended ACL_VPN
permit ip 20.20.20.0 0.0.0.255 10.10.0.0 0.0.0.255
!
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
crypto map VPN_L2L
!
crypto ikev2 profile IKev_Profile
match fvrf frontdoor
match address local 10.10.10.1
match identity remote address 20.20.20.55 255.255.255.255
ivrf Customer_X
!
ā08-03-2024 06:20 AM
I confuse here
What is in your site
Remote LAN
Local LAN
And also
Are you use policy based vpn or route based vpn
And if you route based vpn what is the IP of tunnel ypu use in both peer
MHM
ā08-03-2024 07:02 AM
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
!
ā08-02-2024 09:27 PM
route based tunnel there should be no issues, even policy based there are ways to overcome this.
For route based tunnel **make sure** the tunnel endpoints tunnel source (peer ip) are not going over the tunnel otherwise you get recursive routing. The way to do it is to add /32 static routes for the tunnel endpoints to go through the physical interface (outside) and not over the tunnel. then put /24 route to point to the tunnel interface.
Please rate this and mark as solution/answer/helpful, if this resolved your issue or is helpful
Good luck
ā08-03-2024 01:46 AM - edited ā08-03-2024 07:03 AM
I tried doing what you suggested but unfortunately it didn't seem to have any different. Just to make sure that I understood your suggestion correctly, here is the configuration:
Site A:
Peer IP: 10.10.10.1 , LAN 10.10.0.0/24
Site B:
Peer IP 20.20.20.55, LAN 20.20.20.0/24
!
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.55 255.255.255.255 GigabitEthernet0/5 10.10.10.3
ip route vrf Customer_X 20.20.20.0 255.255.255.0 Tunnel5
!
BTW would it be possible that the LAN in Site A communicate with the IP address of the tunnel endpoint in Site B ?
Can you ping the tunnel endpoints in IPsec ?
ā08-03-2024 08:21 AM
@Ab26 wrote:
ip route vrf Customer_X 20.20.20.55 255.255.255.255 GigabitEthernet0/5 10.10.10.3
ip route vrf Customer_X 20.20.20.0 255.255.255.0 Tunnel5
!
Change the VRF of the static route to the VPN peer to the frontdoor VRF.
ip route vrf frontdoor 20.20.20.55 255.255.255.255 10.10.10.3
ā08-03-2024 08:53 AM
Thansk Rob!
I've tested what you've suggestion but unfortunately it didn't work. There's already a default route for the frontdoor vrf pointing at the router's internet interface.
Any other suggestion please?
ā08-03-2024 09:12 AM
@Ab26 If you have a default route via the frontdoor vrf and the internal networks are in a different VRF then you don't need a /32 for the peer IP.
In the previous posts above you appear to have provided a policy based VPN (crypto map) and routed based (vti) configuration.
What are you using? and is the tunnel established?
It would be better if you provided your configuration so we can determine what exactly is configured.
ā08-03-2024 09:35 AM - edited ā08-03-2024 10:46 AM
I appreciate you trying to help Rob! I have explained everything earlier
ā08-03-2024 10:48 AM
Thanks @Rob Ingram !
The tunnel's IP address 169.254.0.5/32 is just a dummy address, the same concept as "ip unnumbered X" and it not set on the remote site. I've been using the same concept for a while, and it hasn't been an issue at all. This IP isn't advertised out.
The difference here as stated is the remote Peer IP address and the remote LAN are in the same subnet. First I don't know if this is a problem as I have never configured a VPN peer with similar IP senario before and I've never seen it anywhere. I've looked at many configuration on the internet last couple days and none has something similar
Then if you know for sure that this isn't a problem, then does my typical config work or do I have to change something?
The VPN tunnel is up and here's the output of IPsec sa
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
#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.10.10.1, remote crypto endpt.: 20.20.20.55
plaintext mtu 9150, path mtu 9216, ip mtu 9216, ip mtu idb GigabitEthernet0/5
current outbound spi: 0xC1B526A6(3249874598)
PFS (Y/N): Y, DH group: group14
inbound esp sas:
spi: 0xEA15D2D7(3927298775)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 9638, flow_id: HW:7638, sibling_flags FFFFFFFF80000048, crypto map: Tunnel5-head-0
sa timing: remaining key lifetime (k/sec): (4608000/195)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xC1B526A6(3249874598)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 9637, flow_id: HW:7637, sibling_flags FFFFFFFF80000048, crypto map: Tunnel5-head-0
sa timing: remaining key lifetime (k/sec): (4608000/195)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
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#
ā08-03-2024 10:55 AM
@Ab26 I tested your scenario and it will work with a route based VPN.
Example:
interface Tunnel1
vrf forwarding CUSTOMER-X
ip address 172.21.1.1 255.255.255.255
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 2.2.2.1
tunnel vrf FRONTDOOR
tunnel protection ipsec profile IPSEC-PROFILE
!
interface Loopback10
vrf forwarding CUSTOMER-X
ip address 10.10.0.1 255.255.255.255
!
ip route vrf FRONTDOOR 0.0.0.0 0.0.0.0 1.1.1.254
ip route vrf CUSTOMER-X 2.2.2.0 255.255.255.0 Tunnel1
R1#ping vrf CUSTOMER-X 2.2.2.3 source lo10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.3, timeout is 2 seconds:
Packet sent with a source address of 10.10.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/38 ms
R1#
*Aug 3 17:37:41.587: ICMP: echo reply rcvd, src 2.2.2.3, dst 10.10.0.1, topology BASE, dscp 0 topoid 2
From the remote peer side
interface Loopback0
vrf forwarding LAN
ip address 2.2.2.3 255.255.255.255
!
R2#show run | i route
ip route vrf LAN 10.0.0.0 255.0.0.0 Tunnel1
R2# debug ip icmp
*Aug 3 17:37:43.199: ICMP: echo reply sent, src 2.2.2.3, dst 10.10.0.1, topology BASE, dscp 0 topoid 1
*Aug 3 17:37:43.218: ICMP: echo reply sent, src 2.2.2.3, dst 10.10.0.1, topology BASE, dscp 0 topoid 1
R2#show crypto ipsec sa | i encaps|decaps
#pkts encaps: 122, #pkts encrypt: 122, #pkts digest: 122
#pkts decaps: 134, #pkts decrypt: 134, #pkts verify: 134
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