cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1580
Views
6
Helpful
21
Replies

IPsec VPN with a peer IP address and remote LAN in the same subnet

Ab26
Level 1
Level 1

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
!

1 Accepted Solution

Accepted Solutions

@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 

View solution in original post

21 Replies 21

Do you use ASA FW?

MHM

Thanks for your reply! from our end we use a Cisco router

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

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
!

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

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
!

ccieexpert
Spotlight
Spotlight

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

 

Ab26
Level 1
Level 1

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 ?


@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

 

Ab26
Level 1
Level 1

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? 

@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.

Ab26
Level 1
Level 1

I appreciate you trying to help Rob! I have explained everything earlier  

Ab26
Level 1
Level 1

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#

@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