> I remember doing a single line in screenos unless my recollection is off. > > On the Cisco ASA/PIX, it's a single line 'static (inside,outside) > ....' statement. > Is there an equivalently efficient method on the SRX? > > Thank you in advance for any input. > >
Arp-proxy is needed to attract traffic towards the SRX. E. g. if your ISP-facing interface has address 66.x.y.2/27, and 66.x.y.1/27 is your ISP's gw address, the ISP's router will newer send traffic towards 66.x.y.6 and 66.x.y.18 to you, unless one of the following is configured: a) Arp-proxy on the SRX side, b) Longer route like "66.x.y.18/32 -> 66.x.y.2" on the ISP side c) Static ARP entry of the ISP side: "66.x.y.18 has the SRX's external iface MAC address" Otherwise it will ask for ARP 66.x.y.18 and won't get a reply. Of course the first point is the best choice. If your ISP routes traffic towards 66.x.x.18 to you (e. g. you announce them 66.x.y.0/24) using other addresses on the PE-CE link, you don't need arp-proxy. Yes, in ScreenOS and PIXOS, when you configure MIP/Static NAT, a proxy-arp entry is automatically created. But in case of destination NAT (ScreenOS speak, I don't remember how it's called in ASA) it is not. Moreover until the very latest release of ScreenOS (only 6.4 IFAIR) you can not configure arp-proxy for destination nat. We were suffering from this for ages. In my opinion, new NAT logic is a strong point of SRX in comparison to SrceenOS. I find very clever the idea to separate NAT rules totally from routing (for source nat you don't bind pools to interfaces) and from FW policies and to separate the arp-proxy settings. Yes, it adds some complexity to config files and can be not comprehensive from the first glance for people from different worlds, but this is much more flexible. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
