Hello Matt,
I'm afraid there is some unexpected competition between NAT statements.
the show ip nat translations during the test from 10.0.0.27 to 10.33.0.254 tells us the following:
your outgoing traffic is not going over the VPN because it is NATTED using the public address of gi0/0.2 !!!
Here's the nat translations whilst running a ping from 10.0.0.27
icmp 103.212.217.42:96 10.0.0.27:1 10.33.0.254:1 10.33.0.254:96
Looking at configurations related to gi0/0.2 we see the following:
! exit interface hit by NAT from 10.0.0.27 ICMP to 10.33.0.254
interface GigabitEthernet0/0.2
description *PKF INTERFACE*
encapsulation dot1Q 41
ip address 103.212.217.42 255.255.255.252
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
!
! incoming interface for traffic originated from 10.0.0.27/24 is the following directly connected
! internal interface for PKF network notice 10.0.0.0/24 is a connected network
interface GigabitEthernet0/1.40
description *PKF VLAN*
encapsulation dot1Q 40
ip address 10.0.0.253 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip policy route-map PKF_MAP
Here a PBR route-map is applied.
The route-map has the following configuration
route-map PKF_MAP permit 10
match ip address PKF_IP_ACL
set ip next-hop 103.212.217.41
!
The ACL used in the route-map is the following:
ip access-list extended PKF_IP_ACL
>>>deny ip 10.0.0.0 0.0.0.255 10.33.0.0 0.0.0.255
permit ip 10.0.0.0 0.0.0.255 any
permit ip 192.168.150.0 0.0.0.255 any
The ACL has been modified and the first deny statement for interesting traffic should allow the traffic destined to 10.33.0.254 to be not policy routed but to be subject to standard destination based routing.
Destination based routing would make the traffic to exit from gi0/0 main interface using the default route.
However, there are NAT statements using a standard ACL as I have noted in previous post. and NAT operation can take precedence over routing. It is a question of order of operations.
ip nat inside source list PKF_NAT interface GigabitEthernet0/0.2 overload
ip access-list standard PKF_NAT
permit 10.0.0.0 0.0.0.255
permit 192.168.150.0 0.0.0.255
This standard ACL does not allow to deny traffic originated from 10.0.0.0/24 to net 10.33.0.0./24.
We should use an extended ACL as I had proposed on my post.
We can also add a match interface as a security measure to make NAT to be triggered only if the outgoing interface is gi0/0.2 and not when it is gi0/0.
Looking at NAT static commands I cannot see any static NAT command related to host 10.0.0.27.
The only possible NAT triggered here is the one triggered by ACL PKF_NAT.
For your commodity I post again the proposed configuration with added check on exiting interface that should solve your issue (this time I am more confident thanks to Grant's help)
you must use an extended ACL that is then invoked by a route-map to perform NAT
ip access-list extended PKF_NAT2
deny ip 10.0.0.0 0.0.0.255 10.33.0.0 0.0.0.255
permit ip 10.0.0.0 0.0.0.255 any
permit ip 192.168.150.0 0.0.0.255 any
route-map PKF_NAT2 permit 10
match address PKF_NAT2
match interface gi0/0.2
!
no ip nat inside source list PKF_NAT interface GigabitEthernet0/0.2 overload
ip nat inside source route-map PKF_NAT2 interface gi0/0.2 overload.
The PBR on incoming interface gi0/1.40 is already fixed as we have seen above.
As noted by Grant and me you have a very complex NAT and PBR configuration and you need to be sure that no PBR is performed (this is already fixed) and no unwanted NAT can occur.
This is still to be fixed using the configuration proposed above.
When configuring so complex NAT scenarios all NAT statements should use route-maps in order to be able to use:
a) an extended ACL to decide what should be NATTED with deny statements if needed as in this case
b) using a match interface the NAT statement will be used only if the outgoing interface is the specified one avoiding unwanted unexpected translations to occur before standard destination based routing is taken in account.
Hope to help
Giuseppe
