Forum Discussion
SNAT by Destination IP
I want to mask a network behind an SNAT IP address based on the following criteria: either the leaving interface (WAN) or the desitination IP. Is there a way to solve that by configuration utility? Or do I need to write an intelligant SNAT iRule? Any suggestions? Currently I have 3 Interfaces. The customer interface (network) should be able to send traffic to the internet, by passing the f5 external Interface with an SNAT. But the customer network is also able to communicate to other RFC1918 networks via f5 internal interface. Unfortunatelly when I configure an SNAT, the customers network IP is always translated, even if the traffic is send through internal interface. This leads into routing errors. Can somebody help?
10 Replies
- What_Lies_Bene1
Cirrostratus
You'll need an iRule I'd say and a Virtual Server to run it through. The VS will only need to be enabled on the customer network. Apply the SNAT to the VS and also an iRule that simply checks the destination IP (you can check for an egress interface) and if it matches one of the internal networks (perhaps listed in a data group) simply disable the SNAT. If you need help with any of that, let me know.
- Kim_Kipp_49723
Nimbostratus
I already have a wildcard virtual server connected to all interfaces. So I can append the iRule to that virtual server. Well I'm not that familar with iRule, just at the beginning. So it would be very helpful if you can post some syntax.
Network 192.168.10.16/28 should be natted to x.x.x.x if it is going out on interface "TestWAN". If it is going out on interface TestLAN it should not be natted. The network 192.168.10/16 is not a direct attached network to F5!
- What_Lies_Bene1
Cirrostratus
Just putting something together now. As I said it can't be done based on egress interface, only destination IP/subnet. Is there more than one?
- What_Lies_Bene1
Cirrostratus
So, assuming you don't apply the SNAT to the Virtual Server and want to do it all with an iRule, something like this will work if the TESTLAN destination is a single subnet;
when CLIENT_CONNECTED { Check if the client source IP is from the internal network if { [IP::addr [IP::client_addr] equals 192.168.10/16] } { If so, check if the destination IP is in the TESTLAN if { [IP::addr [IP::local_addr] equals x.x.x.x/xx] } { If so, don't SNAT snat none } If not, SNAT else { snat 'name or snat here or specific address' } } } - Kim_Kipp_49723
Nimbostratus
Tried this already, but it doesn't work. when logging the value [IP::remote_addr] it's showing the client IP, same as [IP::client_addr]. This is very strange to me. Cross-checked it twice... Log example: "client 192.168.10.30 remote 192.168.10.30 SNAT yes" Might this happen because of the wildcard virtual server?
- JRahm
Admin
IP::remote_addr is a context sensitive command and depends on whether you use it in a clientside or serverside event. On the clientside events, IP::remote_addr will be the client address, on the serverside, it will be the server address. IP::local_addr is also context sensitive and will be the virtual server on the clientside and the self or snat on the serverside (unless you are doing some vip targeting vip configuration, and then it could be an internal address). IP::client_addr on the otherhand, will always be the client IP regardless of context. - What_Lies_Bene1
Cirrostratus
Doh! Updating the post now - always gets me.
- Kim_Kipp_49723
Nimbostratus
hast to be [IP::local_addr]...
- Kim_Kipp_49723
Nimbostratus
instead of remote_addr
- StephanManthey
Nacreous
I think it could be done without using iRules.
Have network routes and a default route configured first in your network settings. Have specific network virtual servers (ForwardingIP) for your RFC1918, protocol 'all' and port 'any'. Have an additional wildcard network virtual server on 0.0.0.0/0 (ForwardingIP), protocol 'all' port 'any' with SNAT AutoMap enabled. Most specific virtual servers will apply. Now you should be done. Don´t forget to enable SNAT for 'All protocols':tmsh modify ltm global-settings general snat-packet-forward enabled tmsh save sys config tmsh run cm config-sync to-group device-group-failoverOtherwise your PINGs to the outside world will not be SNATed.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com