Configuring policy-based static NAT, together with dynamic NAT, on SR520

[IanLyon222]

Hi,

I'm trying to combine dynamic and static NAT on an SR520.

My dynamic NAT is specified with:

ip nat inside source list 1 interface Dialer0 overload

access-list 1 permit 192.168.0.0 0.0.7.255

In addition to this I want to perform static NAT for a couple of selected internal hosts. I can do this:

ip nat inside source static 192.168.1.5 10.85.10.2

which works fine but means that the source address 192.168.1.5 is translated to 10.85.10.2 for all destination IPs. What I want is for the above static translation only to occur for a particular destination subnet.

To accomplish this I have tried:

ip nat inside source static 192.168.1.5 10.85.10.2 route-map toOtherSite

route-map toOtherSite permit 10

match ip address 150

access-list 150 permit ip 192.168.1.0 0.0.0.255 192.168.10.0 0.0.0.255

But this does not appear to work. Instead it seems to render the host 192.168.1.5 unable to progress through the NAT, whether the destination subnet is 192.168.10.0/24 or not, and I can't work out what I'm doing wrong.

Any help gratefully received.

Many thanks, Ian.

[Andrew Hickman]

Hi Ian,

You can just add some specific port detail for the applications you need to forward to you original config line:

ip nat source static interface Dialer0

Inside port number is what the local host is expecting to see, outside port number is what the remote client sends. Often these will both be the same, but you can use this to translate if you like (either to "hide" services on a non-standard port, or to differentiate between a common application running on multiple local clients).

For example:  ip nat source static tcp 192.168.75.10 80 interface Dialer0 8080.

You can add similar lines for all of the applications you need to allow in. (Don't forget to add permit rules on your inbound firewall configuration to allow the forwarded traffic in in the first place).

HTH

Andy

[IanLyon222]

Andy,

Many thanks for the reply. I had wondered about filtering by port but, unfortunately, it isn't really what we're trying to achieve. I may have to go down that sort of route if I can't get anything else to work, but in the first instance what I'm trying to understand is why the route-map argument isn't working.

I've noticed that what I said in my previous post wasn't quite correct. The situation is that the simple static NAT command:

ip nat inside source static 192.168.1.5 10.85.10.2

appears to work 'as advertised', whereas:

ip nat inside source static 192.168.1.5 10.85.10.2 route-map toOtherSite

does not.

You might have thought that if the 'toOtherSite' route map just matches an access list of 'any source, any destination' the effect should be the same as the previous line (ie without the route-map argument). But it isn't - I've tried. Instead, the very presence of the route-map argument appears to filter out all traffic. The static entry:

Pro Inside global         Inside local          Outside local         Outside global

--- 10.85.10.2            192.168.1.5           ---                   ---

is still present in the NAT translation table but it's as if it's no longer used. Pinging from the 192.168.1.5 host generates dynamic NAT entries (courtesy of my dynamic NAT command line - see previous post) but they're not translated to 10.85.10.2.

So, in practice, the effect of adding the route-map argument is exactly the same as removing the static NAT command altogether, and I'm finding that more than a little counter-intuitive, not to mention counter- what the documentation appears to be saying.

I have wondered whether this feature isn't supported on my hardware. The route-map option certainly pops up in the CLI interactive help but does this mean that it will work on my hardware? I've tried to find the answer to that on the web but failed.

As ever, any enlightenment gratefully received.

Cheers, Ian.