Hi
Interesting question. I tried it in my lab with the following setup: the
traffic is going from zone "hr" (routing-instance "hr") to zone "untrust"
(routing-instance "untrust"). I'm using a pool for S-NAT having 1 address
3.3.3.3/32. My config for NAT is
lab@srxA-1# show security nat
source {
pool spool1 {
address {
3.3.3.3/32;
}
}
pool spool2 {
routing-instance {
untrust;
}
address {
3.3.3.3/32;
}
}
rule-set rs1 {
from routing-instance hr;
to routing-instance untrust;
rule 10 {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
pool {
spool2;
}
}
}
}
}
}
whether I am using spool1 or spool2 in the above config, it works fine, even though
spool1 is in "default" routing instance (and the traffic does not even pass it):
lab@srxA-1# run show security nat source pool all
Total pools: 2
Pool name : spool1
Pool id : 4
Routing instance : default
Host address base : 0.0.0.0
Port : [1024, 63487]
Total addresses : 1
Translation hits : 220
Address range Single Ports Twin Ports
3.3.3.3 - 3.3.3.3 0 0
Pool name : spool2
Pool id : 5
Routing instance : untrust
Host address base : 0.0.0.0
Port : [1024, 63487]
Total addresses : 1
Translation hits : 94
Address range Single Ports Twin Ports
3.3.3.3 - 3.3.3.3 4 0
In both cases, translations work fine
lab@srxA-1# run show security flow session
Session ID: 1908, Policy name: default-policy/2, Timeout: 2, Valid
In: 172.20.101.10/848 --> 172.31.15.1/48900;icmp, If: ge-0/0/4.101, Pkts: 1, Bytes: 84
Out: 172.31.15.1/48900 --> 3.3.3.3/7996;icmp, If: ge-0/0/3.0, Pkts: 1, Bytes: 84
Seems to me that the only reason for having routing-instance in S-NAT pool is
to allow for use of overlapping ip addresses in pools. In the above example,
if I omit routing-instance in spool2 definition, I have error
lab@srxA-1# commit
[edit security nat source pool spool2]
'address'
The address of Source NAT pool(spool2) overlaps with another range [3.3.3.3, 3.3.3.3]
error: configuration check-out failed
So if you have a (rare) situation when you need overlapping ip addressing in S-NAT pools,
you can distinguish the pools by routing-instance. However, it turns out that it does not matter
which routing instance you specify in pool definition (it does not have to coincide
with traffic source and/or destination instance).