NAT inside IPSec tunnel and OSPF - Cisco Routers

[RSTP]

Hello. 

I am attaching a lab network diagram for something I need to implement. All Cisco routers. 

 

GOAL:

Local site subnet 192.168.10.0/24 needs to talk to Remote site subnet 192.168.20.0/24 and 192.168.30.0/24, and vice versa.

Local side subnet 192.168.10.0/24 must be nat’d using the 192.168.200.3 through 192.168.200.6 pool when leaving the Local site to talk to Remote site subnet 192.168.20.0/24 and 192.168.30.0/24.

So far:

OSPF and IPSec tunnel operational and traffic moving okay when "ip nat outside" and "ip nat inside" commands are not applied.

But traffic and encryption gets intermittent when "ip nat outside" and "ip nat inside" commands are applied. 

Which int should NAT be applied?
LOCAL WAN router outside interface – not working? 
LOCAL WAN router inside interface?

Syntax of overload command? 

Static routes pointing to tunnel int T1?

OSPF routing is straight forward, all subnets area 0. Nothing too technical. 

What's missing? Came across IPsec NAT Transparency "no crypto ipsec nat-transparency udp-encapsulation" but not sure it applies. 

Or there is a fundamental flaw in this design and just not going to work with the parameters provided.

Any guidance much appreciated. Unable to share configs. 

[MHM Cisco World]

IPSec is P2P protocol so it not support OPSF, you need tunnel like GRE to run OSPF between two router and sure your can protect it with IPSec.

for NAT I don't exactly get your Q. but you can config NAT in outside for any traffic not pass through IPSec tunnel "I.e. not hit the IPSec ACL".

[RSTP]

Thank you @MHM Cisco World for taking the time to write and your guidance. 

OSPF and the tunnel works fine with the config that is active and the local subnet 192.168.10.0/24 can talk to remote subnet 192.168.20.0/24 192.168.30.0/24 the and vice versa. Also read up on https://community.cisco.com/t5/other-network-architecture/ospf-over-ipsec/m-p/3682196/highlight/true#M197414 

Our requirements is that when the local site subnet 192.168.10.0/24 leaves the local site at that time the local site subnet 192.168.10.0/24 must be nat'd to a different subnet (in this case 192.168.200.0/29) and it also needs to be encrypted (that is why the ipsec). This is where all the issue is happening. It is boggling my mind as to how to make the local site subnet 192.168.10.0/24 nat to 192.168.200.3 - .6 before it leaves the Local WAN Router outside interface and steps into the ipsec tunnel interface to get encrypted as seen in the pic. Still in lab and keep trying. 

Thank you again for your input. 

[RSTP]

Did some more lab in GNS3 2.2.20 

• Attaching cfg files for the routers
• Can see the local side PC 10.10 trace over the tunnel to reach remote PC 20.10 and vice versa
• STILL UNABLE TO FIGURE OUT how to make local subnet 192.168.10.0/24 NAT TO 192.168.200.0/29 before it gets into the tunnel and then make it talk to remote subnets 20.0 and 30.0.
  • Added some config in the LOCAL-WAN-RTR to make NAT work, no joy. Removed the crypto map command from int. Got confusing.

LocalPC10> trace 192.168.20.10
trace to 192.168.20.10, 8 hops max, press Ctrl+C to stop
1 192.168.10.250 2.052 ms 1.480 ms 1.510 ms
2 192.168.110.1 5.507 ms 3.276 ms 2.561 ms
3 10.1.1.1 7.460 ms 6.272 ms 6.345 ms
4 172.16.110.2 8.303 ms 7.349 ms 7.062 ms
5 *192.168.20.10 7.609 ms

LocalPC10>

RemotePC2010> trace 192.168.10.10
trace to 192.168.10.10, 8 hops max, press Ctrl+C to stop
1 192.168.20.250 1.733 ms 1.982 ms 1.332 ms
2 172.16.110.1 2.301 ms 1.885 ms 2.239 ms
3 10.1.1.2 6.458 ms 6.473 ms 7.147 ms
4 192.168.110.2 8.228 ms 7.101 ms 7.577 ms
5 *192.168.10.10 8.850 ms (ICMP type:3, code:3, Destination port unreachable)

RemotePC2010>

Local-WAN-RTR NAT CONFIG:

interface Tunnel1
ip address 10.1.1.2 255.255.255.252
ip ospf 10 area 0
tunnel source 192.168.200.2
tunnel mode ipsec ipv4
tunnel destination 192.168.200.1
tunnel protection ipsec profile P
!
interface GigabitEthernet0/0
ip address 192.168.110.1 255.255.255.252
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
ip address 192.168.200.2 255.255.255.248
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45

crypto map MAP 10 ipsec-isakmp
set peer 192.168.200.1
set transform-set TS
match address NAT-SUBNET

ip nat pool NAT-POOL 192.168.200.3 192.168.200.6 prefix-length 29
ip nat inside source list LOCAL-SUBNET pool NAT-POOL overload
ip route 192.168.20.0 255.255.255.0 Tunnel1
ip route 192.168.30.0 255.255.255.0 Tunnel1
!
ip access-list standard LOCAL-SUBNET
permit 192.168.10.0 0.0.0.255 log
!
ip access-list extended NAT-SUBNET
permit ip 192.168.200.0 0.0.0.7 192.168.20.0 0.0.0.255 log-input
permit ip 192.168.200.0 0.0.0.7 192.168.30.0 0.0.0.255 log-input

[Giuseppe Larosa]

Hello @RSTP ,

post show ip nat translations

Paul Driver is right  in your tests from PC 20.10 you should attempt to reach the Global address 192.168.200.x as the internal address should be hidden .

Depending on your OSPF configuration the internal addresses can be advertised. But this would make NAT useless just an exercise in a lab.

From the way you have written the ACL for interesting traffic you are assuming that NAT happens before traffic is placed on the tunnel.

This is the reason why I would like to see show ip nat translations

The tunnel 1 is the real L3 exit interface.

Edit:

I have checked on local LAN router and you have OSPF running on the subnet

>>

network 192.168.10.0 0.0.0.255 area 0

Hope to help

Giuseppe

[paul driver]

Hello

---

192.168.10.0/24 must be nat’d using the 192.168.200.x

RemotePC2010> trace 192.168.10.10

---

NAT is applied on the correct rtr, what i can see is your trying to ping the hidden subnet thats being natted, The whole idea of nat is "hide" the original network so what you should be pinging is it NOW natted address.  192.168.200.x not anything on the hidden natted network which shouldn't be advertised.

Also remove the logging from the NAT acl

no ip access-list standard LOCAL-SUBNET
ip access-list standard LOCAL-SUBNET
permit 192.168.10.0 0.0.0.255

[RSTP]

Thank you @Giuseppe Larosa and @paul driver for taking the time to write and your guidance. 

At this time, the LOCAL WAN Router is not showing any ip nat translations data. ip nat statistics show that the config exists, but no translations are happening. 

LOCAL LAN Router sure is running OSPF for the 192.168.10.0/24 subnet to send it to the upstream LOCAL WAN Router = did you mean don't do that? 

The RemotePC2010> trace 192.168.10.10 and LocalPC10> trace 192.168.20.10 were done as the first step to observe successful OSPF exchange, followed by the second step to observe the encryption of traffic passing through the tunnel.

When got to the third step of NAT, then things got confusing - ip nat translations were empty. I made crypto map, but I understand that crypto map is only needed on the outgoing physical interface if not using the VTI - which in my config I am. Paul mention of the "hidden" NAT made me realize that since we are to hide local subnet from remote subnet and that is why we are doing the nat, the only one starting the conversation here is the local subnet. 

I will lab some more given these new ideas:

// Change ACL for local subnet

// Test with no OSPF between the tunnel interfaces

// Remove the "ip route 192.168.10.0 255.255.255.0 Tunnel1" on the Remote-WAN router also - test with and without

// Test with VTI as is and check for nat translations 

// Test with NO VTI and WITH crypto map on LOCAL WAN router's outgoing physical interface Gi0/1 and check for nat translations 

Looks like makings of a weekend overload due to nat overload.

Thank you again. 

[Giuseppe Larosa · Accepted solution]

Hello @RSTP ,

if ip nat translations are not happening this means that the ip nat outside interface should be configured on interface Tunnel and not on the Physical interface.

And yes normally the NATTed subnet is not advertised to outside world. But it is not this that is preventing NAT from happening.

Standard source NAT is triggered when traffic is received on an interface with ip nat inside and it has to be sent out a L3 interface with ip nat outside. In your case the L3 outgoing interface is the GRE p2p tunnel for the IP routing table.

The fact that your NAT pool is made of IP addresses in the same IP subnet as the GE exit interface does not help too.

The return traffic would be likely sent out of the tunnel if the Outside Global addresses are seen as directly connected by the other router.

You could use a loopback interface representing the NAT pool so that it can be advertised in OSPF with a different IP subnet.

I think this could help when adding NAT. I use this trick to advertise a NAT pool and it works you need ip ospf network point-to-point under the loopback configuration to have OSPF advertise the correct prefix (without that command  OSPF would advertise a /32 for the loopback regardless of the true subnet mask)

Hope to help

Giuseppe

[RSTP]

Thank you @Giuseppe Larosa . Appreciate additional guidance and clarity on the matter. I agree that using the same subnet for NAT as the outside is not a great design but I need to do my best to make this happen. 

Thank you again. Will update when things start working. 

[RSTP]

Happy to share @Giuseppe Larosa you are a genius and of course you knew that. 

// Edited the LOCAL-SUBNET ACL

// Added the ip nat outside to int T1 on LOCAL WAN Router

// Removed the LOCAL SUBNET 192.168.10.0/24 from the OSPF statements

// Added ospf point-to-point on WAN router physical int

// Added a static route in LOCAL WAN Router to point to LOCAL SUBNET 192.168.10.0/24

and NETWORK MAGIC!!! NAT translations, icmp response, everything going good now. See trace below from LOCAL PC to Remote PC, exactly what needed to happen.

Although the tunnel ip and remote router int IPs are obscured in the trace, but the results are what needs to be. Not sure if the int tunnel ip should be visible in the trace or doesn't matter? Thoughts? 

Local-WAN-RTR#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.200.3:6657 192.168.10.10:6657 192.168.20.10:6657 192.168.20.10:6657
icmp 192.168.200.3:6913 192.168.10.10:6913 192.168.20.10:6913 192.168.20.10:6913
icmp 192.168.200.3:7169 192.168.10.10:7169 192.168.20.10:7169 192.168.20.10:7169
icmp 192.168.200.3:7425 192.168.10.10:7425 192.168.20.10:7425 192.168.20.10:7425
icmp 192.168.200.3:7681 192.168.10.10:7681 192.168.20.10:7681 192.168.20.10:7681
icmp 192.168.200.3:7937 192.168.10.10:7937 192.168.20.10:7937 192.168.20.10:7937
icmp 192.168.200.3:8193 192.168.10.10:8193 192.168.20.10:8193 192.168.20.10:8193
icmp 192.168.200.3:1024 192.168.10.20:6657 192.168.30.10:6657 192.168.30.10:1024
icmp 192.168.200.3:1025 192.168.10.20:6913 192.168.30.10:6913 192.168.30.10:1025
icmp 192.168.200.3:1026 192.168.10.20:7169 192.168.30.10:7169 192.168.30.10:1026
icmp 192.168.200.3:1027 192.168.10.20:7425 192.168.30.10:7425 192.168.30.10:1027
icmp 192.168.200.3:1028 192.168.10.20:7681 192.168.30.10:7681 192.168.30.10:1028
udp 192.168.200.3:47040 192.168.10.20:47040 192.168.30.10:47041 192.168.30.10:47041
Local-WAN-RTR#

LocalPC10> trace 192.168.20.10
trace to 192.168.20.10, 8 hops max, press Ctrl+C to stop
1 192.168.10.250 3.949 ms 5.143 ms 3.748 ms
2 192.168.110.1 12.101 ms 9.942 ms 5.437 ms
3 * * * 
4 * * *
5 * * *
6 192.168.20.10 17.633 ms 13.726 ms 15.595 ms

LocalPC10>

LocalPC20> trace 192.168.30.10
trace to 192.168.30.10, 8 hops max, press Ctrl+C to stop
1 192.168.10.250 3.715 ms 6.406 ms 5.223 ms
2 192.168.110.1 9.137 ms 7.445 ms 8.055 ms
3 * * *
4 * * *
5 * * *
6 192.168.30.10 17.542 ms 13.883 ms 22.713 ms

LocalPC20>