NimbostratusI have a setup where vip and pool member ip's are on the same network....pool members need to see the real client ip address....but this is not http/https so i can't simply create a header with client ip. any ideas?
Cirrostratus
NimbostratusPlease help, I may have the same issue.
We are having issues with client connections in our new HL7 environment.
We set up multiple clients on the same VIP and same pool member on the F5.
Each client has their own port which is how we keep them separated
Clients are using a site to site VPN to connect.
This worked when we tested over the internet. The only difference is that we are using a site to site VPN.
Clients claim they do not get an acknowledgement when they send a message. The external firewall shows that we are indeed sending an acknowledgement. Also, a simple telnet from the client to the VIP over the port specified shows they are indeed connected.
However, when I run wireshark on the HL7 server that sits behind the F5 and filter by the client’s port, I see nothing. If it’s not getting to the server, what is responding? The F5? I fear it may be a SNAT issue but we are using SNAT automap.
Can someone more clearly define how the F5 handles this traffic once it hits the F5? Should I be able to see the clients address and port on the server or does the F5 hide that information?
virtual HL7_Client1 {
snat automap
pool pool_hl7_Client1
destination 205.xxx.xx.xx:8888
ip protocol tcp
persist source_addr
profiles {
Http_compression {}
tcp {}
}
}
virtual HL7_Client2 {
snat automap
pool pool_hl7_Client2
destination 205.xxx.xx.xx:9999
ip protocol tcp
persist source_addr
profiles {
Http_compression {}
tcp {}
}
}
pool pool_hl7_Client1 {
lb method member least conn
action on svcdown reselect
monitor all gateway_icmp
members 10.10.10.10:8888 {}
pool pool_hl7_Client2 {
lb method member least conn
action on svcdown reselect
monitor all gateway_icmp
members 10.10.10.10:9999 {}
CirrostratusNimbostratusThanks very much. At least I know why my packet captures are not showing anything on the server. I have to prove to our Dev group that the traffic is actually getting to the server. Can you please give me a breif description of what the F5 does to the traffic so I can explain this to them?
Nimbostratus
Just for further context.....this is dns traffic, internal and external.
Nimbostratus
Just for further context.....this is dns traffic, internal and external.
Cirrostratus
https://devcentral.f5.com/community/group/aft/85951/asg/52
I don't see a way around turning off SNAT and finding a way to get return traffic to the F5.
Cirrocumulus
Policy routing (As mentioned above) to ensure that the traffic passes back via the BigIP. You could configure this on the client (e.g. With Linux using iptables to mark the traffic and a specific route for that marked traffic only) or on the VLAN gateway (router) itself
With tcp traffic you can add an option header to insert the clients real-ip. But your server needs to understand how to get that value and what to do with it. And it's not going to help UDP traffic.... However... There are provisions within the DNS protocol that you could take advantage of. You could insert another QTYPE record within the UDP query for a class of traffic that doesn't exist, and insert the clientip into there... Again, your DNS server software would have to know what to do with it... So that's probably not going to be very useful.
The easy way of course is to hide the DNS servers BEHIND the BigIP and get rid of SNAT, using the BigIP as the route back to the clients doing the querying.
H