NimbostratusHello Experts
My scenario is some what like, we have user machines which will be trying to access an internal portal page, which will be resolved to internal IP. This IP will be used as VIP on F5. When this request will hit the VIP, the pool associated with it is FQDN, lies on the internet.
Now I want is when user open the internal portal page, it get proxied to external FQDN.
Need Help. I am new to FQDN and F5 both.
If you are running 11.6.0, you can use FQDNs as pool members. This is described in detail here:
You would also need to SNAT the connection:
If you are using a version prior to that, and the target must be an FQDN, you'll have to use an iRule. You should read the information regarding the
RESOLV::lookupthen use something like this (untested!):
when RULE_INIT {
set static::rf_target_fqdn "www.example.com"
}
when CLIENT_ACCEPTED {
set alist [RESOLV::lookup -a $static::rf_target_fqdn]
if { [llength $alist] > 0 } {
node [lindex $alist 0]
} else {
log local0.warn "Failed to resolve hostname ($static::rf_target_fqdn)"
reject
}
}
There are (at least) three drawbacks here: 1.
RESOLV::lookup
Nimbostratus
EmployeeIf you are running 11.6.0, you can use FQDNs as pool members. This is described in detail here:
You would also need to SNAT the connection:
If you are using a version prior to that, and the target must be an FQDN, you'll have to use an iRule. You should read the information regarding the
RESOLV::lookupthen use something like this (untested!):
when RULE_INIT {
set static::rf_target_fqdn "www.example.com"
}
when CLIENT_ACCEPTED {
set alist [RESOLV::lookup -a $static::rf_target_fqdn]
if { [llength $alist] > 0 } {
node [lindex $alist 0]
} else {
log local0.warn "Failed to resolve hostname ($static::rf_target_fqdn)"
reject
}
}
There are (at least) three drawbacks here: 1.
RESOLV::lookupI would recommend using
tcpdumpand check /var/log/ltm to ensure that there are no errors. Since you have the http profile applied, the flow should look like this in a tcpdump:
CLIENT BIG-IP SERVER
--- SYN ---> |
<-- SYN/ACK --- |
--- ACK ---> |
--- ---> |
+ --- SYN --->
+ <--- SYN/ACK ---
+ --- ACK --->
+ --- --->
where REQHDR are the request headers. On the second half (between the BIG-IP and the SERVER), the source address will be the SNAT source address (172.16.254.50).
Having said all of that, the SNAT source address on the BIG-IP (172.16.254.50) must be able to reach the public addresses (since it's an RFC 1918 address, I assume it is subject to further address translation somewhere else?) and there must be a route back to that address.
NimbostratusI would recommend using
tcpdumpand check /var/log/ltm to ensure that there are no errors. Since you have the http profile applied, the flow should look like this in a tcpdump:
CLIENT BIG-IP SERVER
--- SYN ---> |
<-- SYN/ACK --- |
--- ACK ---> |
--- ---> |
+ --- SYN --->
+ <--- SYN/ACK ---
+ --- ACK --->
+ --- --->
where REQHDR are the request headers. On the second half (between the BIG-IP and the SERVER), the source address will be the SNAT source address (172.16.254.50).
Having said all of that, the SNAT source address on the BIG-IP (172.16.254.50) must be able to reach the public addresses (since it's an RFC 1918 address, I assume it is subject to further address translation somewhere else?) and there must be a route back to that address.
Nimbostratus
AltostratusBe careful when using FQDN-nodes as they may break the ability to update iApps. Don't know if HF5 resolved this issue, but HF4 still had the problem.
EmployeeSNATing makes tcpdump captures somewhat tricky, because you cannot (obviously) use source address to match the client- and server-sides of the flow. However if, during your testing, you have only a single flow active at a time, it is pretty easy. Reduce your pool to one member. Assuming it is a member only in that pool, then you would capture using:
tcpdump -nni 0.0 host or host
So, if your VS address is 10.10.10.1 and your pool member is 172.16.254.100:
tcpdump -nni 0.0 host 10.10.10.1 or host 172.16.254.100
If you have more than one flow at a time, you'll need to add some higher layer information to match the flows. For example, you could something like Fiddler or Developer Tools on Chrome/Firefox to insert an arbitrary header (say X-Track, with an arbitrary value). That header will be proxied, and you can use it to match the client-side and server-side flows.