Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

SNAT Based on Source and Destination

I hope you can help ... thanks.

I am trying to apply conditional SNAT based on source and destination for any service otherwise leave them alone and allow the static NAT to take effect. What I did is ...

NOTE: The client servers normally have static NATs applied.

1. Created Forwarding (IP) VIP available only on the VLAN where the client servers reside with the following configuration:

virtual vsANY-NodeNet
destination any:any
disable
ip forward
rule snat_rule
vlans NodeNet enable

NOTE: NodeNet is the VLAN where the client servers reside.

2. Created an iRule labeled 'snat_rule' as follows:

when CLIENT_ACCEPTED {
if {[matchclass IP::local_addr eq $::the_destination_ip] and [matchclass IP::client_addr eq $::the_source_ip]} {
snat 10.10.1.1
} else {
snat none ### i tried using 'forward' here too
}
}

2a. I tried this too:

when CLIENT_ACCEPTED {
if {[matchclass IP::local_addr eq $::the_destination_ip]} {
snat 10.10.1.1
} else {
snat none ### i tried using 'forward' here too
}
}


The result was that all traffic matched the rule and everything started failing, because traffic destined for the internal network is subjected to specific firewall rules, which include source, destination and port as the rule parameters. After this new iRule, the server static NATs are not applied rather all get the 10.10.1.1 SNAT, which obviously is not in any of the firewall rules.

Technically the iRule could be based on matching the destination only but I included the source too as I thought that it will be less invasive/more efficient the more specific it is. Was I correct?

HELP !!!
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
The VIP is showing disabled in your config snippet--I assume it was enabled when you were testing? Also, the IP::client_addr and IP::local_addr commands need to be enclosed in square braces in order to be executed. I would think that the conditional should have failed and no SNAT would have been used.

Can you retest with the VIP enabled and the commands bracketed?

  
when CLIENT_ACCEPTED {
if {[matchclass [IP::local_addr] equals $::the_destination_ip] and [matchclass [IP::client_addr] equals $::the_source_ip]} {
log local0. "[IP::client_addr]: using SNAT for [IP::local_addr]"
snat 10.10.1.1
} else {
log local0. "[IP::client_addr]: not using SNAT for [IP::local_addr]"
snat none
}
}


Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Thanks for the reply Aaron.

You are correct, the VS was enabled when I was testing.

I re-enabled the VS and tried your rule but no luck ... most outbound traffic still failed.

I got the following error message when your rule tried to compile:

01070394:3: TCP::client_port in rule (snat_rule) requires an associated TCP profile on the virtual server (vsANY-NodeNet). I can't really assign a TCP profile on a Forwarding (IP) VS, can I?

Therefore, for this test I just cut the [TCP::client_port] portion of the log statement.

I also could not find where the logged the "[IP::client_addr]:using SNAT" result.

Thanks for your help. Do you have any other suggestions?

Cheers ...
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
You're correct... the TCP:: command won't work on a forwarding VIP. Can you take out [TCP::client_port] from the rule as listed above?

Once the rule runs without a TCL error, the log output will be written to /var/log/ltm. You can use 'tail -f /var/log/ltm' to watch the log statements written to the file.

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I took out the '[TCP::client_port]' statement when I tried it the first time as soon as I got the compile error. I tried it again and same behavior, outbound traffic is failing and nothing in th e'ltm' log.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Can you add a log statement to the SNAT none case? And can you post the contents of the class? You can anonymize the networks if they're public. You can list the class contents using:

b class the_destination_ip list

and

b class the_source_ip list

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I added the log statement and still nothing logged ... and definitely still failing.

class the_destination_ip {
host 1.111.34.133
host 1.111.34.135
host 1.111.34.136
host 1.111.34.137
host 1.111.34.138
host 1.111.34.139
host 1.111.34.140
host 1.125.30.135
host 1.125.30.202
host 1.125.30.211
}

class the_source_ip {
host 2.175.43.16
host 2.175.43.25
}

The first octet is obviously not real.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
If nothing gets logged with both conditions in the rule being logged, I'd guess that either the clients aren't on the nodenet VLAN (which you've said they are) or the NAT is taking precedence over/conflicting with the forwarding VIP. Can you try deleting the NAT for one of the servers and retest?

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
The servers are definitely members of the NodeNet.

I will not be able to reach the servers at all if I delete the NAT, so that would not be a good test. There must be something wrong in the concept of using VS to all destinations, services, and protocols with this type of iRule. I don't know if I clarified this well enough but when I enable the new VS and iRule, just outbound traffic from the servers fails, I can still reach the servers, hence inbound traffic and the actual NAT must be working.

I am totally lost.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I was suggesting to delete the NAT as a way to test if it's being used for the outbound connection instead of the wildcard VIP. To replace the NAT functionality (at least the inbound portion) can you remove the NAT for one server, add a new VIP on the NAT address on port 0 pointing to a pool containing the server also on port 0? You can then retest the outbound connection from the server through the wildcard VIP with the iRule without the NAT impacting the traffic flow.

Else, maybe a support case would allow you to get someone to look over your exact configuration and provide a more detailed response?

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
The LTM does not track connections for NAT addresses, so they cannot be shared with virtual servers or SNAT's. As Aaron is suggesting, you'll need to revise your inbound flow configuration to achieve your goals.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
That can't be true citizen_elah. I already have similar rules/configurations. The only difference between this one and the other ones is that the others have a more specific VS, e.g. it is a wildcard destination but specific service and protocol. This one is a wildcard on everything ... destination, service, and protocol. I don't see how that would affect it but I would not place any bets either as I am not that familiar with the LTM internals.

Anyway, the good news is that I made progress.

First, I resolved my 'outbound traffic failing' problem by rearranging the rule a little as follows:

when CLIENT_ACCEPTED {
if { [matchclass [IP::client_addr] equals $::the_source_ip]} {
if { [matchclass [IP::local_addr] equals $::the_destination_ip]} {
snat 10.10.1.1
} else {
forward
}
}
}

Don't ask me why or how, but flipping the source and destination match clause positions and changing from an 'and' to multiple 'if' statements fixed it.

Second, I was still not getting any hits on the SNAT or any signs of live packets going in that direction. Just for fun I synchronized the config with the standby unit and went to test from it ... everything worked as expected. Then failed over the current Active unit and it is still working. Now I have to figure out what is wrong with the original Active unit that it works half way only. The curious thing is that all other configurations I have on it work fine and nobody is complaining or reporting any anomalies.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Then the documentation is wrong. I'd be really curious to see a scrubbed version of your configuration.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I can certainly offer any configuration pieces of interest to you.

Now the funny part ... I found why it wasn't working on the primary unit. It is a port issue. I noticed few other anomalies on the device. One of them was that inbound and outbound PING tests to the port used in the iRule were visible in tcpdump on the interface but not really acknowledged with a Reply or Timeout. I switched the VLAN cable to another vacant port on the device and everything is working as expected. What a crazy case.

Thanks for your help and guidance and sorry for the false alarm ... I am calling F5 tech support for RMA now.

Cheers ...
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I have posted on this link below before I saw this thread. I know this is old thread, but it appears similar to my problem.

https://devcentral.f5.com/questions/two-snat-irule-with-same-origin-ip-addresses-54056#comment50703

The SNAT1 VIP is currently 443 and SNAT2 VIP is only port 80.

I want some SSL traffic going through SNAT2 as well (443 and 80).

The SNAT1 traffic is only to two destinations, which could be URL or IP address.

The goal is to add https traffic to SNAT2 (https and http) via irule.

If https and http SNAT to SNAT2 virtual IP (default)

If https://www.abc123.com and/or https://www.utts123.com SNAT to SNAT1 virtual server.

I am running version 12.1.1. There used to be SNAT rule on version 10.x where you can define the ip addresses, but it appears missing on 12.x.

0