[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