[c-nsp] NAT w/ VRF routing

[Garry]

Hi,

I recon I'm missing something basic here, but after some hours of trying 
and testing, I just can't seem to pinpoint a solution ...

Here we go ...

In our quest of finding a decent firewall that can do VRF routing with 
overlapping address ranges, we have finally scrapped (read: returned) 
the POS Lucent Brick firewall and have decided to give the Firewall IOS 
of Cisco a try.

We have set up a 7200VXR w/ 12.4(7a) IOS. Dual FE to start off with, one 
for the outside connection, one for inside/VRFs. So, something like this:

interface FastEthernet0/0.112
  description Customer$FW_INSIDE$
  encapsulation dot1Q 112
  ip vrf forwarding CUSTOMER
  ip address 10.112.1.5 255.255.255.0
  ip access-group sdm_fastethernet0/0.112_in in
  ip access-group sdm_fastethernet0/0.112_out out
  ip nat inside
  ip virtual-reassembly
  no snmp trap link-status

interface FastEthernet0/1
  description $ETH-LAN$$FW_OUTSIDE$
  ip address a.b.x.y 255.255.255.0
  ip address a.b.z.1 255.255.255.0 secondary
  ip access-group 101 in
  ip verify unicast reverse-path
  ip flow ingress
  ip flow egress
  ip nat outside
  ip inspect SDM_LOW out
  ip ips sdm_ips_rule in
  ip virtual-reassembly
  ip route-cache flow
  duplex auto
  speed auto
  mpls ip
  mpls mtu 1520

VRF routes are up and running fine, I can reach all the places inside 
the CUSTOMER vrf. Anyway, I tried to configure some trial NAT now:

ip nat inside source static network 10.112.0.11 a.b.z.2 /32
	vrf CUSTOMER

Now, this does seem to work fine on the way from outside to inside:

fw-ffm#show ip nat tr vrf BUHL
Pro Inside global      Inside local       Outside local      Outside global
icmp a.b.z.2:35410 10.112.0.11:35410 c.d.42.30:35410 c.d.42.30:35410
--- a.b.z.2      10.112.0.11        ---                ---

but somehow the returning packets aren't de-natted:

dustpuppy:~ # ping a.b.z.2
PING a.b.z.2 (a.b.z.2) 56(84) bytes of data.
64 bytes from 10.112.0.11: icmp_seq=1 ttl=248 time=26.2 ms
64 bytes from 10.112.0.11: icmp_seq=2 ttl=248 time=32.9 ms

In order not to disrupt the regular service, I had added a network route 
to get from inside the VRF to the outside - I asume this is causing the 
problem, somehow bypassing the NAT rule:

ip route vrf CUSTOMER c.d.42.0 255.255.255.0 FastEthernet0/1 a.b.64.1

What am I missing here?

tnx, -gg