Forum Discussion

Kim_Kipp_49723's avatar
Kim_Kipp_49723
Icon for Nimbostratus rankNimbostratus
Sep 18, 2013

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

  • 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.

     

  • 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's avatar
      What_Lies_Bene1
      Icon for Cirrostratus rankCirrostratus
      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?
  • 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'
       }
     }
    }
    
  • 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's avatar
      JRahm
      Icon for Admin rankAdmin
      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.
  • 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-failover
    

    Otherwise your PINGs to the outside world will not be SNATed.