Forum Discussion
nitass_89166
Feb 20, 2015Noctilucent
How do I apply the pool to the SNAT?
you can use simple irule something like this. you also need to make sure server knows where to send return traffic e.g. routing, arp.
configuration
root@(ve11b)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
ltm virtual bar {
destination 172.28.24.10:80
ip-protocol tcp
mask 255.255.255.255
pool foo
profiles {
fastL4 { }
}
rules {
qux
}
source 0.0.0.0/0
vs-index 6
}
root@(ve11b)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm pool foo
ltm pool foo {
members {
200.200.200.101:80 {
address 200.200.200.101
}
}
}
root@(ve11b)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
ltm rule qux {
when CLIENT_ACCEPTED {
scan [IP::client_addr] %*d.%*d.%d.%d c d
snat 192.168.$c.$d
}
}
trace
[root@ve11b:Active:In Sync] config tcpdump -nni 0.0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
13:38:36.981475 IP 172.28.24.1.50638 > 172.28.24.10.80: S 2519421337:2519421337(0) win 5840
13:38:36.981607 IP 192.168.24.1.50638 > 200.200.200.101.80: S 2519421337:2519421337(0) win 5840
- Feb 20, 2015Using exactly this approach (with "getfield" but "scan"; but like the scan-based approach better (+1)) in a client´s environment. No problems by now and client has a one-by-one mapping allowing simplified troubleshooting. As nitass already pointed out, make sure to have a route back to the virtual address space used for SNAT. The route (on your peripheral components) will point to the serverside floating self IP of the BIG-IP.