Policy based routing on Juniper Netscreen firewalls

Thanks for the tip about "Bypassing PBR"!

Just curious if PBR can help conserve the interface address when dealing with a limited Internet IP situation. For example, I've moved away from interface based NAT toward policy based NAT, however the one thing I loved about interface NAT is the ability to utilize the untrust interface IP as a VIP and perform "port forwarding" using the actual interface IP as well as additional VIPs. In a situation where I'm cramming a ton of services on to a 5 IP subnet, this was most helpful.

Obviously the problem I have with policy based nat is the route portion, which using routing tables alone means the route for the untrust interface IP is already set and routed to the untrust interface. Since PBR policies are processed before the standard routing table is checked, could I route traffic bound for the untrust interface IP address based on port/protocol? For instance, could I take traffic bound for port 80 on the untrust interface IP and route it to the trust zone using a policy? This is something I cannot do with policy based NAT and the standard routing tables alone.

If possibly, could you walk me through an example of the ACL and group setups required to do this? Thanks very much!

Hmm I seem to be having a problem creating an intra-zone policy that works. Does the "Block Intra-Zone Traffic" checkbox (yes, I'm a GUI loser) have to be checked or unchecked to allow intra-zone policies to work, or is it irrelevant?

Are you available for consulting? I have a complex setup (I think it's complex anyway) that I need some serious help on. It's a non-production setup so it's safe to tinker on, I just need some assistance grasping some concepts and figuring out a config that will work for what we're trying to do.

Upon further testing, it seems our SSG20 will not properly translate traffic bound for the firewall interface IP. I removed all routes and inter-zone destination-nat policies in favor of creating intra-zone policies on the untrust zone instead. The policies work for every IP in the subnet except the interface IP. Apparently there is some limitation or perhaps a special config setting unique to the interface IP that I'm missing?

The primary limitations I'm concerned with with VIP are 1) the limited number of VIPs that can be setup, and the limited number of "port forwards" you can setup. 2) SIP through VIP is DOA (just had to use a 3rd acronym there).

I thought I had things all figured out with intra-zone dest-nat policies until I started noticing odd behavior. Some of the policies worked, while others flat out would not. Sometimes none of them would work unless, and this is very odd, I added a VIP. Then they would work, and continue working even if I then removed the VIP.

It got so bad I posted on eLance asking for professional assistance. I've got one taker so hopefully we'll see what I did wrong.

Ahh very interesting. I figured there was something I was missing. I'll give it a go and let you know!

My ScreenOS responds to the command with:

This command is a deprecated command, please use the following new preferred syntax:

set interface proxy-arp-entry [ip_max]

However after reading the KB article I think I'm going to stick with creating a DIP range. The funny thing is when I tried working with VIPs I also tried creating a DIP range and it didn't seem to work correctly, but who knows with ARP caching how long it might take for upstream routers to latch on to the new MAC. Maybe I was impatient.

I suppose I could also coordinate with my upstream provider to flush the ARP cache on their box after I perform the switch-over to the new SSG20 (I'm currently running a 5GT).

I'll give it a shot and let you know.

Well, the interface proxy arp setting appears to be doing the trick with the new public subnet. Once I get the time to attempt a swap-out of our 5GT for the SSG 20 again, I'll set proxy arp entries for the current production subnet and send an update.