01-30-2024 06:59 PM - edited 01-30-2024 11:00 PM
We'd like to nat the source private IP from our AWS end over IPSec VPN tunnel on another end, which is Cisco CSR 1000v router, here is the diagram. IPSec VPN is configured with route-based via tunnel interface with AWS end, we'd like to nat 10.251.15.102 to 189.40.1.x on CSR1000v when it reaches node1 (10.15.25.23) sitting behind the customer CE router which default gateway is set to 189.40.1.3 and untouchable,
here is setting on CSR1000v in terms of natting:
int tunnel1
ip nat inside
int GigabitEthernet2.3217
ip add 189.40.1.1 255.255.255.240
ip nat outside
ip access-list extended NATList
permit ip 10.251.15.0 0.0.0.255 any
ip nat inside source list NATList interface GigabitEthernet2.3217 overload
no natting triggerred at all after above setting:
sh ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
GigabitEthernet2.3217
Inside interfaces:
Tunnel1
Hits: 0 Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 8] access-list NATList interface GigabitEthernet2.3217 refcount 0
any assistance is appreciated.
01-30-2024 09:42 PM - edited 01-30-2024 09:42 PM
Hello @david.wang
sh ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
GigabitEthernet2.3217
Inside interfaces:
Tunnel1
Hits: 0 Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 8] access-list NATList interface GigabitEthernet2.3217 refcount 0
---
Tunnel 1, not 0 ?
01-30-2024 10:59 PM
typo, the interface is tunnel1 which is configured with "ip nat inside", there is no tunnel0.
01-30-2024 11:21 PM
Hello @david.wang ,
the NATList is wrong - it should be
permit ip any 10.251.15.0 0.0.0.255
given the nat inside/outside configuration.
01-30-2024 11:30 PM
I did update NATList as you said as below, but same, nothing triggerred:
sh run | s access-list
ip access-list extended NATList
10 permit ip any 10.251.15.0 0.0.0.255
01-31-2024 12:00 AM
Hello @david.wang
Try to add ip nat inside command under your tunnel source interface.
02-01-2024 05:08 PM
sorry for late reply, being busy. yes, i did add it on the tunnel source interface as well, but not working. anyway, i figured it out by myself due to vrf setting as the actual requirement is for reaching multi-customers with overlapping private subnet from AWS end, which sounds for me to have to use vrf. I am still setting up the whole config, and may ask you guys here if required, thanks.
01-31-2024 01:08 AM
I fast run lab and test
the NAT is working good in my lab
but since you run NAT overload so the traffic is only NAT if come from AWS to Node1
this due to NAT overload is unidirectional not bidirectional
if you need traffic to NAT from NODE to AWS and from AWS to NODE you need to add static NAT
02-01-2024 05:13 PM
again sorry for late reply. as i mentioned above reply, I did figure it out due to vrf, and looks overload working, but good to know overload is unidirectional. I may ask you guys again if required while setting up multiple customer with overlapping subnet via vrf, thanks.
02-01-2024 06:03 PM
Dont worry
Glad issue solved
MHM
02-12-2024 03:06 PM - edited 02-12-2024 08:28 PM
now we need to nat the reverse direction as well, the initiate traffic is from node to AWS, and the nat is dnat: from 10.15.25.23 to 189.40.1.1 natted to from 10.15.25.23 to 10.251.15.102, I am testing via using static one "ip nat inside source static 10.251.15.102 189.40.1.1" to see how's going, will post the result after it.
02-12-2024 08:19 PM
I think it work, and thanks for update us
Goodluck
MHM
02-13-2024 12:18 AM
yes, it works for single customer, but rather than multiple customers with overlapping private subnet from AWS end, here is the up-to-date diagram:
3 customers, customer 2 & 3 overlapping:
customer1: private subnet 10.15.221.0/24, only reachable via public IP 187.40.1.x/28
customer2: private subnet 10.15.25.0/24, presented by public ip 189.40.1.x/28,
customer 3, private subnet 10.15.25.0/24, presented by public ip 201.40.1.x/28
set up ipsec tunnel2 specifically for customer3 due to their private subnet is same as customer2, share ipsec tunnel1 for reaching customer 1 & 2 since they uses different subnet, currently Monitor1@AWS can access node1@customer1 and node1@customer2, and Monitor2@AWS can reach node1@customer3 via the following nat/route/vrf settings:
interface Tunnel1
ip nat inside
interface Tunnel2
vrf forwarding Cust3
ip nat inside
interface GigabitEthernet2.3213
ip address 187.40.1.1 255.255.255.240
ip nat outside
interface GigabitEthernet2.3217
ip address 189.40.1.1 255.255.255.240
ip nat outside
interface GigabitEthernet3.3027
vrf forwarding Cust3
ip address 201.40.1.1 255.255.255.240
ip nat outside
ip nat inside source list Cust1 interface GigabitEthernet2.3213 overload
ip nat inside source list Cust2 interface GigabitEthernet2.3217 overload
ip nat inside source list Cust3 interface GigabitEthernet3.3027 vrf Cust3 overload
ip access-list extended Cust1
10 permit ip 10.251.15.0 0.0.0.255 10.15.221.0 0.0.0.255
ip access-list extended Cust2
10 permit ip 10.251.15.0 0.0.0.255 10.15.25.0 0.0.0.255
ip access-list extended Cust3
10 permit ip 10.252.3.0 0.0.0.255 10.15.25.0 0.0.0.255
ip route 10.15.25.0 255.255.255.0 GigabitEthernet2.3217 189.40.1.2
ip route 10.15.221.0 255.255.255.0 GigabitEthernet2.3213 187.40.1.2
ip route 10.251.15.0 255.255.255.0 Tunnel1
ip route vrf Cust3 10.15.25.0 255.255.255.0 GigabitEthernet3.3027 201.40.1.2
ip route vrf Cust3 10.252.3.0 255.255.255.0 Tunnel2
now the new request is we need to nat the reverse direction properly as well, both directions natting, when the initiate traffic is sent from the customer node to AWS end, we need to translate the dest ip to AWS end ip:
node1.customer1 to monitor1.aws: from 10.15.221.23 to 187.40.1.1 natted to 10.15.221.23 to 10.251.15.102
node1.customer2 to monitor1.aws: from 10.15.25.23 to 189.40.1.1 natted to 10.15.25.23 to 10.251.15.102
node1.customer3 to monitor2.aws: from 10.15.25.23 to 201.40.1.1 natted to 10.15.25.23 to 10.252.3.103
after replacing above "ip nat inside source list Cust3 interface GigabitEthernet3.3027 vrf Cust3 overload" with "ip nat inside source static 10.252.3.103 201.40.1.1 vrf Cust3", it's working for customer3 to AWS, but how can we achieve customer1 & 2 to AWS since both share the same ipsec tunnel? anything special nat setting or other option?
it's a bit longer description, hope it makes sense to you guys.
02-14-2024 04:08 PM
still try to find out the solution of static natting with multiple customers sharing same ipset tunnel, which is described above with latest reply, do we need to use vrf-aware ipsec which I am not familiar? any assistance/advice is much appreciated.
02-14-2024 09:10 PM
just figured it out via using route-map with natting, thanks.
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