so you mean the VPN Clients will be able to access the internal devices of the ASA1 (apart from accessing internet from the same ASA1 ) and devices of other ASA2 as well , if ASA1 and ASA2 have site to site vpn among them (see below ) ?
Inside servers
|
|
ASA2----ASA1----VPN Clients
also , this seems to resemble closely to the "Split tunnel" functionality in the VPN ? right ?
2) have one more query
nat (outside) 0 access-list OUT_NAT outside
access-list OUT_NAT extended permit ip
can we also achieve the above with the help of static policy (identity) nat i.e something like
by using the nat exempt mentioned by fred we can access both the internal servers as well as networks behind ASA2 if you have a site to site vpn configured.
This is totally different from split tunneling.
In Split tunneling we actually differentiate the traffic that is supposed to flow through the VPN tunnel from the clients end.
in case you access-list as follows in the split tunnel : access-list split standard permit 10.0.0.0 255.255.255.0
We mention that we need to send all traffic to 10.0.0.0 through the VPN tunnel and rest all other traffic need not be encrypted.
Your 2nd Query:
We could also implement it using the Static policy Nat as suggested by you . But the only condition being the traffic has to be initiated from the source mentioned in the access-list. Until then there would not be a entry in the xlate table.
NAT exempt is bi-directional and it doesnt create an entry in the xlate table where as policy nat is unidirectional and hence traffic has to be sourced from the source ip mentioned in the access-list to create entry in the xlate table.
thanks for explaining it praveen , but the below nat is only for the low to higher source identity translation as it has outside keyword and i dont think it will be bidirectional , though the NAT exempts are bidirectional
nat (outside) 0 access-list OUT_NAT outside
access-list OUT_NAT extended permit ip
Also static identity policy nat is bidirectional . this below eg. will act as a source translation for outside (lower to higher) and destination dranslation from higher to lower .right ?
The usage of the keyword " outside" purely defines the static as a destination Nat and hence you will need a source nat also
The policy Nat is bi-directional but after an Xlate entry is created. Hence the traffic has to be initiated from the source mentioned in the access-list.
For example :
Static (inside,outside) 10.1.1.0 access-list test
access-list test permit ip 10.0.0.0 255.255.255.0 11.0.0.0 255.255.255.0
where 10.0.0.0 is on inside and 11.0.0.0 is on the outside.
The traffic has to be initiated from 10.0.0.0 only then there would be a entry in the xlate.
once there is a entry in the xlate the entry works as bidirectional.
1) i am still not clear if this is a bidirectional NAT ? in my views i dont think so it is bidirectional (usually NAT exempts are bidirectional but this is not )
2) as per you the "outside" keyword purely defines the static as a "destination Nat" .i dont think is true as in below example we are doing a source identity translation (assuming VPN CLIENT from outside initates the traffic)
static (outside,inside) access-list OUT_NAT access-list OUT_NAT extended permit ip
3) just for my curiosity there is one example you mentioned below and indeed this has nothing to do with the above two
Static (inside,outside) 10.1.1.0 access-list test access-list test permit ip 10.0.0.0 255.255.255.0 11.0.0.0 255.255.255.0
where 10.0.0.0 is on inside and 11.0.0.0 is on the outside.
my ques : is it necessary that xlate will be created when 10.0.0.0 will intiate the traffic . what if 11.0.0.0 initates traffic first ?
Q1. whether the below NAT exempt with remote vpn client as source (on out of asa) bidirectional or not?
A1. It is bidirectional.
Q2. is it necessary that xlate will be created when 10.0.0.0 will intiate the traffic . what if 11.0.0.0 initates traffic first ?
A2. An xlate will be created as soon as this static nat is configured. (That is why it is called static).
# show run access-l access-list test extended permit ip 10.0.0.0 255.255.255.0 11.0.0.0 255.255.255.0 # show run static static (inside,outside) 10.1.1.0 access-list test # show xlate 1 in use, 2 most used Global 10.1.1.0 Local 10.0.0.0
regarding 2nd ques , you have mentioned that xlate is created as soon as static nat is configured .
while praveen mentioned following if you see the initial part of this thread (mentioned in " ")
"The policy Nat is bi-directional but after an Xlate entry is created. Hence the traffic has to be initiated from the source mentioned in the access-list.
For example : Static (inside,outside) 10.1.1.0 access-list test access-list test permit ip 10.0.0.0 255.255.255.0 11.0.0.0 255.255.255.0
The traffic has to be initiated from 10.0.0.0 only then there would be a entry in the xlate.once there is a entry in the xlate the entry works as bidirectional"
.
so which one of the above is true ? Thats the reason my question was what if 11.0.0.0 initates the traffic first .
Well, as per the above pasted outputs (again pasted below), the xlate was created as soon as static was configured.
# show run access-li access-list test extended permit ip 10.0.0.0 255.255.255.0 11.0.0.0 255.255.255.0 # show run static static (inside,outside) 10.1.1.0 access-list test # show xlate 1 in use, 2 most used Global 10.1.1.0 Local 10.0.0.0
It would be good to verify this on your ASA as well.
Paps
Learn, share, save
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
