Forum Discussion

Nimbostratus

Jun 05, 2008

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 !!!

14 Replies

hooleylist
Cirrostratus
Jun 05, 2008
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_90
Nimbostratus
Jun 05, 2008
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 ...
hooleylist
Cirrostratus
Jun 05, 2008
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
Maxim_Taskov_90
Nimbostratus
Jun 05, 2008
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.
hooleylist
Cirrostratus
Jun 05, 2008
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
Maxim_Taskov_90
Nimbostratus
Jun 05, 2008
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.
hooleylist
Cirrostratus
Jun 05, 2008
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
Maxim_Taskov_90
Nimbostratus
Jun 05, 2008
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.
hooleylist
Cirrostratus
Jun 05, 2008
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
JRahm
Admin
Jun 05, 2008
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.