- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-09-2012 10:56 AM
I have the following rule in the firewall and was wondering if I needed to create a second rule for the other direction or if the bi-directional option will take care of it for me.
example
source address :10.100.10.50 > destination address: FTPSERVERSGROUP > Source Translation: static-ip 209.165.241.88 bi-directional
Basically if 10.100.10.50 is going to any of the IPs in the FTPSERVERSGROUP I want it to get translated to 209.165.241.88, and I also want the flip of anything coming from FTPSERVERSGROUP to 209.165.241.88 get translated to 192.168.1.10.
I just want to make sure I don't need a source translation and then a destination translation or if the bi-directional option will take care of it....
08-10-2012 01:27 PM
OK, I assume your rule looks more like this:
src-zone=dmz > dstzone=untrust > src-address=(10.100.10.50) > dst-address=(address-group) > src-translation=static-ip, (209.165.241.88), bi-directional > dst-translation=none
It is still bidirectional. A destination address without destination will only 'restrict' the matching traffic.
For 'outgoing' traffic if the destination needs to match the address-group and for 'incoming' traffic the source has to match the address-group.
Keep in minde that the positioning of the rule also determines if it will be matched or not. The NAT rule base is also 'read' top to bottom.
08-10-2012 11:21 AM
Anyone tried this before?
08-10-2012 11:47 AM
We have a few bi-directional NAT rules in place.
i.e. dmz > untrust > src-address (private-ip) > src-translation static, (public-ip), bi-directional
This works well for us for incoming and outgoing traffic for our mail and web server.
You just need to have the appropriate security rules in place to allow the traffic.
08-10-2012 11:58 AM
Ok so I was able to Lab this up and these are the results.
Original Packet
Source: 192.168.1.254 (INSIDE)
Destination: SERVER GROUP (OUTSIDE)
Source Static Translation
172.16.1.1 (OUTSIDE)
Bi-Directional - Yes
Ok so on workstation 192.168.1.254 I am able to ping all of the IP's in the server group and NAT looks to be working correctly outbound. If I try to ping anything other than the server group it fails as expected (since it doesn't match destination).
However I am then able to ping (192.168.1.254) from anything via (172.16.1.1) inbound. I was hoping that it would only NAT it if the source was from the server group, which is not the case.
So it looks as though I have to disable bi-directional and manually create a destination NAT sourced from SERVER GROUP destination 172.16.1.1
08-10-2012 01:27 PM
OK, I assume your rule looks more like this:
src-zone=dmz > dstzone=untrust > src-address=(10.100.10.50) > dst-address=(address-group) > src-translation=static-ip, (209.165.241.88), bi-directional > dst-translation=none
It is still bidirectional. A destination address without destination will only 'restrict' the matching traffic.
For 'outgoing' traffic if the destination needs to match the address-group and for 'incoming' traffic the source has to match the address-group.
Keep in minde that the positioning of the rule also determines if it will be matched or not. The NAT rule base is also 'read' top to bottom.
08-10-2012 03:23 PM
Right so in this configuration, if 10.100.10.50 is going to anything in the (address group) it will get translated to 209.165.241.88. And then ANYTHING hitting 209.165.241.88 from the outside will get translated to 10.100.10.50 according to my lab.
What I wanted was for the source of the inbound to be limited to only the (address group). To accomplish this I need a second destination NAT for it to work how I want.
Thanks again for the help!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!