Forum Discussion
Maxim_Taskov_90
Nimbostratus
NimbostratusSNAT 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 !!!
hoolioCirrostratus
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
Maxim_Taskov_90Thanks 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 ...- hoolioYou'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 - Maxim_Taskov_90I 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.
- hoolioCan 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 - Maxim_Taskov_90I 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. - hoolioIf 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 - Maxim_Taskov_90The 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. - hoolioI 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 - JRahm
Admin
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.
