Forum Discussion
Franky-frank-reg7
Altocumulus
AltocumulusF5 SMTP Fast Template - SNAT Not working as expected
Hello all,
I'm having issues with getting SMTP to work with the FAST templates. Specifically, I'm trying to configure an SMTP template with no SNAT option checked so the backend pool members received the original clients IP address, but while running debugs we're seeing the server consistently received traffic with the F5's self IP address.
I'm tried to toggle between checking and unchecking the checkbox in the SMTP FAST template for SNAT and automap, but even when completely disabled the feature and creating a new template, the servers are still seeing the F5 self IP's as the source of traffic. Can anyone suggest what might be the fix here? Below is a SNIP of my configuration:
Note: There is no VLAN filtering, TLS termination, or anyting special very plain vanilla configuration.
Franky-frank-reg7 That is true but to simplify the configuration so that you reduce the man hours you might/will spend in the future troubleshoot a non-standard deployment of the F5 you should deploy it as option 1
- Paulius
MVP
Franky-frank-reg7 If the virtual server configuration does not have SNAT enable then it should not be performing SNAT. Are you positive the traffic that you are receiving from the F5 isn't health monitors to the pool members? I ask this because the health monitor will come from the F5 and most likely appear as legitimate traffic in a tcpdump. I recommend running the following tcpdump to see what's happening with your traffic when you attempt to use the virtual server.
tcpdump -nni 0.0:nnp host <SMTP_VS_IP> -w /shared/tmp/smtp_tshoot.pcap
The tcpdump mentioned will save a file named smtp_tshoot.pcap to directory /shared/tmp/ which you can copy off and then open in wireshark to see what's happening with your traffic.
Franky-frank-reg7The traffic is definitely making it through the VIP, we configured the template with the domain name "mycompanytest.com", and it's exaclty what appears in the output of the SMTP logs on the server.
- Paulius
Franky-frank-reg7 What does the virtual server and any associated configuration look like? Do you see SNAT enabled on the virtual server?
- Franky-frank-reg7
It's a very straight forward configuration. There is no SNAT configured, no SSL profiles (Client/Server), or VLAN filters. Please see the snip below:
We just re-tested and it appears it may have been correct, the traffic we saw on the servers were the healthy monitors. The thing I can't describe is why traffic isn't making through the VS, exchange and other applications we deployed with FAST templates are working. Just not SMTP at the moment.
- Franky-frank-reg7
When we send traffic from an app server attempting to relay SMTP traffic to the VIP. On the Exchange server running SMTP we get the output red and black output in wireshark below:
When we directly relay from the app server to the Exchange server. We're getting successful connections as displayed in the blue connections of the wireshark capture above. The only thing I can think of that could potentially be changing connection parameters is the TCP profile, but again these are all default values we're using as part of the template. The Fast template version we're using is listed below. Some please offer your insights. The connections are currently being reset from the exchange server as we can see the output above:
- Paulius
Franky-frank-reg7 Would you mind sharing the entire configuration that relates to this SMTP virtual server so I can take a deeper look? The configuration should be virtual server, tcp profiles, pool, and any associated iRules.
- Franky-frank-reg7
"class": "ADC", "schemaVersion": "3.0.0", "id": "urn:uuid:a858e55e-bbe6-42ce-a9b9-0f4ab33e3bf7", "Exchange2019": { "class": "Tenant", "Exchang2019_SMTP_Internal": { "class": "Application", "template": "generic", "Exchang2019_SMTP_Internal": { "virtualAddresses": [ "10.20.22.228" ], "virtualPort": 25, "snat": "none", "class": "Service_TCP", "pool": "Exchang2019_SMTP_Internal_pool", "profileTCP": "wan", "iRules": [] }, "Exchang2019_SMTP_Internal_pool": { "class": "Pool", "members": [ { "serverAddresses": [ "10.20.22.150" ], "servicePort": 25, "connectionLimit": 0, "priorityGroup": 0, "shareNodes": true } ], "loadBalancingMode": "least-connections-member", "slowRampTime": 300, "monitors": [ { "use": "Exchang2019_SMTP_Internal_monitor" } ] }, "Exchang2019_SMTP_Internal_monitor": { "class": "Monitor", "monitorType": "smtp", "interval": 30, "timeout": 91, "domain": "smtp.regeneron.com", "username": "", "passphrase": { "ciphertext": "", "protected": "eyJhbGciOiJkaXIiLCJlbmMiOiJub25lIn0" } } } } }
- Franky-frank-reg7
Just so it's clear, in this case we only need to preserve client IP as it comes in to the load balancer. The outbound traffic in the scenario above, applies when the server either needs to talk to the Internet or some core infrastructure service i.e DNS. Which does not require original server IP. The key thing is the servers need to see the real client IP, this is only th ingress component, for egress (Internet bound) traffic, there is no requirement to preserve original IP's.
So the question is, can I just SNAT on the forwarding IP VS for traffic leaving the server outbound? To my understanding, this would only change the server's IP as it's headed outbound. For traffic initiated from a client inbound, it will hit the SMTP VS and return through original connection in the connection table on the F5. Is that not the case?
- Franky-frank-reg7
Paulius Any ideas on the question above?
- Paulius
Franky-frank-reg7 That is true but to simplify the configuration so that you reduce the man hours you might/will spend in the future troubleshoot a non-standard deployment of the F5 you should deploy it as option 1