The workaround I found that worked for me was to set a proxy-ID that was the supernet of all the networks reachable through the Netscreen. This works great in a classic telecommuter environment if you use 192.168 networks for your telecommuters, and 10 or 172.16 RFC1918 addresses in your data center/offices. You can literally have the proxy ID of the Netscreen be 10.0.0.0/8 and set the "network" in the Sonicwall to 10.0.0.0 255.0.0.0, and traffic will route properly. If your other networks aren't in a contiguous netblock, or can't be handled as a supernet, then this won't work for you, but it does work. It turns out that the proxy-ID on the netscreen is totally unrelated to any policy element or anything other than the SA. That proxy ID is set as the "network" in the SA in the sonicwall. The sonicwall then forwards all packets for the supernet to the Netscreen, which routes them accordingly.

The only other solution I know of is one SA for each route.

[ reply ]