NimbostratusI am trying to capture the source port coming back from the node but I only get the pool member port. Any idea how I can capture this so I can snat my traffic?
Cirrostratus
What protocol are you working with? Why wouldn't the source port of the node be the pool member port?
Aaron
NimbostratusUsing active FTPS. The source port needs to be what is coming from the node because we need to SNAT our traffic based on a range of source ports coming from the node.
NimbostratusIf you are from CA and like Indian food then you are probably already familiar with this.
Employee
FTPS Offload via iRules by Colin
https://devcentral.f5.com/tutorials/tech-tips/ftps-offload-via-irules
NimbostratusNo. I also asked an engineer last week while in Seattle and he indicated that the CLIENT_ACCEPTED was for client side connections and would not work in firing on the server side events for what we were trying to do.
Employeei thought you are asking about passthrough active mode ftps load balancing, aren't you?
NimbostratusThis is the irule being applied at the any vip.
when CLIENT_ACCEPTED {
log local0.debug "Client_accepted triggered"
log local0.debug "remote addy is [IP::remote_addr] remote port is [TCP::remote_port] local addy is [IP::local_addr] port is [TCP::local_port]"
if { [TCP::remote_port] >= 6500 and [TCP::remote_port] <= 6549} {
log local0.emerg "Matched port range - Remote port was: [TCP::remote_port] "
snat 10.118.48.100 989
}
}
This never seems to fire as far as I can see. If I use something like SERVER_CONNECTED I do see the event firing but it only returns the port of the pool member and not the actual node port. You can see our problem.
Altocumulus
log local0.debug "Client_accepted triggered"
That log line, once uncommenetd, should and must work. You need to understand why it does not, first.