cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
155
Views
0
Helpful
0
Replies
Highlighted
Beginner

CSR1000v ACL/Destination Targeted NAT

Hello All,

 

We have a CSR running in AWS in a transit VPC design and have been using this for NAT'ing to hide the servers private addresses to 3rd party vendors further downstream.

 

Server <--- VPN A (inside) --->  CSR  <--- VPN B (outside) ---> OnPremise <-- 3rd Party Network

 

We have this working for a good amount of systems, where inbound traffic to the NAT IP would go to the server and return and be NAT'd on the way back out. No issues. We then had issues with the NAT where any traffic from the server to on-prem would get NAT'd as it passed the CSR as it is also downstream. In order to fix this outbound issue, we added a route-map and ACL to the NAT rule so that for outbound/return traffic, only traffic destined to the 3rd party would actually get NAT'd and traffic to everywhere else such as on-premise would stay on its internal address. eg:

 

 

ip nat inside source static <internalServerIP> <NATIP> vrf <VPNAVRF> route-map RM_3rdPartyAddress

route-map RM_3rdPartyAddress permit 10
match ip address ACL_3rdPartyAddress

ip access-list extended ACL_3rdPartyAddress
permit ip host <internalServerIP> host <3rdPartyDestinationHost>
deny ip any any

 

 

The above works as expected, only traffic from the internal server to the 3rd parties host address gets NAT'd on its way out.

 

Expanding on the above, we have a scenario where we have 2 3rd Parties, connecting to the same internal server, but we must provide them with a different NAT IP, and traffic coming from the server must be on a specific NAT IP, depending on where the destination traffic is going. Again, we expanded on the above, and in one production NAT and in the LAB, it works as expected.

 

 

ip nat inside source static <internalServerIP> <NATIP_1> vrf <VPNAVRF> route-map RM_3rdParty_2_Address
ip nat inside source static <internalServerIP> <NATIP_2> vrf <VPNAVRF> route-map RM_3rdParty_2_Address

route-map RM_3rdParty_1_Address permit 10
match ip address ACL_3rdParty_1_Address
ip access-list extended ACL_3rdParty_1_Address permit ip host <internalServerIP> host <3rdParty_1_DestinationHost> deny ip any any route-map RM_3rdParty_2_Address permit 10 match ip address ACL_3rdParty_2_Address ip access-list extended ACL_3rdParty_2_Address permit ip host <internalServerIP> host <3rdParty_2_DestinationHost> deny ip any any

 

 

In lab and for one of our production systems, this works. One internal server, but depending on where the traffic is going, may get a different NAT address. You can see below from the LAB that this is working, The same internal server address but 2 NAT addresses, and its using different ones depending on the destination of the traffic. 

LAB NAT.jpg

 

We have went to implement another one of these, however we simply cant get the NAT rule to apply for the new NAT address. The initial one is working, but for some reason the traffic is not being applied. I have checked that the ACL and route-map names match and are spelt correctly. That the inside server address and destination address are correct in the ACL rule.

 

When doing a packet-trace, with fia. I can see that the NAT isnt being applied. In the below, tunnel3 is our VPNA (inside) and tunnel5 is our VPNB (outside)

 

Server <--- VPN A/tunnel3 (inside) --->  CSR  <--- VPN B/tunnel5 (outside) ---> OnPremise <-- 3rd Party Network

 

 

  Feature: IPV4_OUTPUT_TCP_ADJUST_MSS
    Entry       : Output - 0x813c2b34
    Input       : Tunnel3
    Output      : Tunnel5
    Lapsed time : 500 ns
  Feature: MC_OUTPUT_GEN_RECYCLE
    Entry       : Output - 0x813ae3ec
    Input       : Tunnel3
    Output      : Tunnel5
    Lapsed time : 1393 ns
  Feature: IPV4_NAT_OUTPUT_FIA
    Entry       : Output - 0x813b913c
    Input       : Tunnel3
    Output      : Tunnel5
    Lapsed time : 90673 ns

 

 

However doing a trace on the NAT for the existing NAT for the same internal IP... I can see the NAT occurring, the above seems to skip the NAT feature the following one shows:

 

  Feature: MC_OUTPUT_GEN_RECYCLE
    Entry       : Output - 0x813ae3ec
    Input       : Tunnel3
    Output      : Tunnel5
    Lapsed time : 793 ns
  Feature: ALG PARSER
    Type   : FTP ALG
    Caller : NAT
    Action : NO L7 ACTIONS
  Feature: NAT
    Direction   : IN to OUT
    Action      : Translate Source
    Old Address : 10.1.*.34
    New Address : 10.2.*.35
  Feature: IPV4_NAT_OUTPUT_FIA
    Entry       : Output - 0x813b913c
    Input       : Tunnel3
    Output      : Tunnel5
    Lapsed time : 47033 ns

 

As far as I can see, the ACL rule I created exactly matches the source and destination addresses on the non working NAT trace, and also the route map and ACL names are correct so should be matching, and it should all be working just like in LAB test like in the above image. However just cant seem to get it to apply. The NAT rule itself is exact to the existing one, except for the RM and NATIP, (internal IP and VPN VRF match)

 

I cant seem to find any good debuging to see what or why acl's or route maps are being hit or ignored. Are there any good traces or counters that can be put in place to check and further troubleshoot? I tried log on the end of the ACL rule, but got no output whatsover on this.

 

I also tried creating very simple ACL and route map names to remove any spelling or character issues (other are a similar format so it shouldn't be this) and as this is a production system I cant alter too much, but I also tried in the ACL on the new NAT rule to NAT any ICMP traffic from any to any.

 permit ICMP ANY ANY

 

Again, the ICMP traffic inspection showed that the NAT wasn't being hit.

 

Thank You

Rich