Forum Discussion
SNAT Pool on secondary VLAN
Dear Brandon,
this is more a network design and routing question.
In general if you configure a virtual server, the BIG-IP at least performs a destination-NAT (VS-IP -> Poolmember-IP). But to guarantee that response traffic is also coming back through the BIG-IP, most of the time you also have to configure source-NAT (unless the default gateway of the poolmembers is pointing to the BIG-IP).
For this source-NAT you can either choose between SNAT automap, which means the floating IP of the VLAN, which is used depending on the routing table to reach the poolmember, is used. Or you can create a dedicated SNAT pool and specifiy IPs there. Keep in mind as mentioned above, that you need to guarantee, that response traffic is coming back through the BIG-IP. So as long as the poolmembers for your virtual server are reachable via the secondary VLAN, a SNAT pool with IPs from this VLAN should be fine.
Alternatively you can also work with transfer-/link-VLANs. One of our preferred network designs is as following:
- floating VIP-range
- "clientside" transfer-VLAN, which will be used to route the VIP-range towards the BIG-IP
- "serverside" transfer-VLAN, which will be used to route towards the different nodes/poolmembers using static routes
- default route is pointing to the peer of the clientside transfer-VLAN
So at the end it's important to know, which requirements you have from a network design perspective. Based on this you can define the correct SNAT solution.
Hope that helps, otherwise please provide more details about your requirements (maybe also a small network diagram is useful).
Thank you!
Regards Stefan :)
To add to that, referencing the statement around the default gateway on the F5 from my original post, the return traffic from the server will be returning to the self IP of the secondary VLAN - however, the default route is pointed toward the gateway of the primary VLAN - which is a show-stopper. What are the solutions to get around this?
Both VLANs are contiguous so we can always reconfigure the network side to consolidate, which would resolve the issue - however, that's a pretty decent sized undertaking given how many applications we have routing through this LTM...
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com