cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
289
Views
0
Helpful
2
Replies
Beginner

VPN Overlapping Address Space

Hello Everyone,

I've been dealing with this issue for couple of days now. I have an overlapping vpn address space wherein the local networks of both sites are identical. It would be easy if these two sites are both using asa firewall. But that's were the problem is, it isn't. 

The other end an Amazon Web Services VPN tunnel wherein we can only define the ASA's public ip and its inside network. Amazon only sends us the crypto settings that needs to be configured in the appliance

The idea is to trick ASA that the remote local network is 10.131.0.0/16. When the packet leave ASA, the source address became 10.0.30.0/24 with destination of 10.131.0.0/16.

On the remote network (Amazon), the interesting traffic that can be defined is the destination network only. As if the ACL is "access-list ROUTE ext per ip any 10.0.30.0 /24".

I was able to bring the tunnel but looking at the ipsec stats i found this

 

peer address: 205.100.100.22
Crypto map tag: CRY-OUTSIDE, seq num: 131, local addr: 24.24.24.24
access-list CRY-QA-ORE extended permit ip 10.0.30.0 255.255.255.0 10.131.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.0.30.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.131.0.0/255.255.0.0/0/0)
current_peer: 205.100.100.22
#pkts encaps: 1457, #pkts encrypt: 1457, #pkts digest: 1457
#pkts decaps: 645, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 1457, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 645
local crypto endpt.: 24.24.24.24/0, remote crypto endpt.: 205.100.100.22/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 31DE9FFC
current inbound spi : 9540A832
inbound esp sas:
spi: 0x9540A832 (2504042546)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 180224, crypto-map: CRY-OUTSIDE
sa timing: remaining key lifetime (kB/sec): (3915000/2088)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x31DE9FFC (836673532)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 180224, crypto-map: CRY-OUTSIDE
sa timing: remaining key lifetime (kB/sec): (3914880/2088)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

 

The way I understand the above data is we're having issue with the return traffic. ASA is expecting a return traffic with a source address of 10.131.0.0/16 and a destination of 10.0.30.0/24. But what's coming in is a source address of 10.31.0.0/16 and a destination of 10.0.30.0/24.

Is there any way we can NAT this return traffic?

Thanks,

2 REPLIES 2
Rising star

Hi Jonjon,I doubt why they

Hi Jonjon,

I doubt why they use the any as the source @ Amazon.... is that the way they restricted to??? the return traffic from amazon box will not return with the NAted IP???

I believe ASA will treat the return traffic with stateful inspection.... i do not think so it can treat that once again as a new traffic in your case to do NAT...

We can put reverse NAT with source as real IP of customer LAN in ASA but how much that will is a big question.....

ASA inspects with Sequence table to allow the return traffic.... here that would be a problem to do with...

 

Regards

Karthik

Beginner

hi karthik,

hi karthik, yeah, probably its not any, its unsecure. it could be the cidr block choosen when i created my aws network, in this case its 10.31.0.0/16 ill take a look at this reverse nat, its worth giving a shot. thanks, jon