[j-nsp] SRX Static NAT
Pavel Lunin
plunin at senetsy.ru
Thu Mar 3 00:35:42 EST 2011
> 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.
More information about the juniper-nsp
mailing list