[c-nsp] NAT and VRF routing problem

Arie Vayner ariev at vayner.net
Sat Jul 15 11:14:25 EDT 2006


Garry,

I suggest you take a look at these links, you might get some new ideas...

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide09186a008041d91a.html
http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapter09186a008044edb0.html

Arie


On 7/12/06, Garry <gkg at gmx.de> wrote:
> I posted this some time ago, never got any reply ... anybody happen to
> have some insight?
>
> ---
>
> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list