APM - How to configure logging of snat addresses for network access and app tunnels
Hello everyone, we are using BIG-IP Access Policy Manager to enable administrative access to systems via App Tunnel and Network Access resources. For security reasons, we need to be able to map requests logged on backend resources/systems (e.g. in SSH audit logs) to the session or user accessing said backend resource via App Tunnel or Network Access in APM. Currently, the following request information is logged. Network Access: May 17 14:42:00 tmm0 tmm[22565]: 01580002:5: /APM/ap_rmgw:Common:c1237463: allow ACL: #app_tunnel_/APM/Some_App-Tunnel@c1237463:15 packet: tcp 192.168.12.18:58680 -> 10.0.0.1:22 App Tunnels: May 17 14:41:10 tmm1 tmm1[22565]: 01580002:5: /APM/ap_rmgw:Common:c6787463: allow ACL: #app_tunnel_/APM/Some_App-Tunnel@c6787463:0 packet: tcp 89.229.152.144:63252 -> 10.0.0.1:2 For Network Access requests, an IP address of the lease pool configured in the Network Access resource is logged as the client IP. For App Tunnel requests, the public IP of the client accessing APM is logged as the client IP. In our setup, both requests will be NATed by APM before hitting the target system (through a snat pool in case of a Network Access request, through the active appliances backend IP in case of App Tunnels). Therefore, the APM self IPs (snat pool/appliance backend) will be logged on the target host, leading to us not being able to correlate logs in APM with logs on the target systems. Is there any way to log the SNAT/NAT addresses and ports used to access target systems through APM? I've tried using ACCESS_ACL_ALLOWED in an iRule to log additional information, unfortunately this event only seems to trigger on Portal Access resources, not when using App Tunnels or Network Access resources. Thank you, FabianDNS: reply from unexpected source
Hi, Firstly, I must say that I am a complete newbie when it comes to BIG-IP products. On the other hand, the load balancer was configured by experts, so I am pretty confident that they made a reasonably good job. I have two DNS servers (DNS1 and DNS2) and a BIG-IP F5 14.1.4.6 load balancer. Both DNS servers' default gateway is the F5. When a DNS client asks the DNS service in the F5, the load balancer sends the request to one of the DNS servers keeping the client's IP. Then, on receiving the reply from the DNS server, the F5 sends the reply to the client using its own IP (with SNAT). This way, the DNS client only talks to the F5. On the other hand, when a DNS client ask one of the DNS servers directly, the DNS server sends the reply to the default gateway (the F5) and the packet is routed to its destination without any change. Nevertheless, every now and then I am facing replies from unexpected sources. For instance, sometimes the client asks DNS1 but it gets the reply from the F5. Thus, I get messages like this: ;; reply from unexpected source: bigip#53, expected dns1#53 It looks like that, on receiving the reply from DNS1, the F5 replaces the packet's source IP (SNAT) with its own ip. Example: Right behaviour: PC -> DNS query to F5 service -> F5 -> sends a query to DNS1 or DNS2 keeping the PC's source IP -> DNS1 replies to the F5 (its default gateway) -> F5 replaces source IP (SNAT) and sends the reply to the PC -> the PC receives the reply from the service it asked to. PC -> sends a DNS query to DNS1 -> DNS1 replies to the F5 (its default gateway) -> the F5 somehow knows that the reply was sent directly to DNS1 and forwards the reply to the PC keeping DNS1's IP address -> the PC receives the reply from the server it asked to (DNS1). Wrong behaviour PC -> sends a DNS query to DNS1 -> DNS1 replies to the F5 (its default gateway) -> the F5 replaces the packet's source IP (DNS1) with its own IP and forwards the reply to the PC -> the PC receives the reply from an unexpected server (F5). Can you give me a hand to solve this? Maybe you can just give me a hint to start looking for the solution. Thanks in advance. Regards,SSL Orchestrator Advanced Use Cases: Outbound SNAT Persistence
Introduction F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases. If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility. SSL Orchestrator Use Case: Outbound SNAT Persistence It may not be the most obvious thing to think about persistence in the vein of outbound traffic. We are all groomed to accept that any given load balancer can handle persistence (or "affinity", or "stickiness") to backend servers. This is an important characteristic for sure. But in an outbound scenario, you don't load balance remote servers, so why on Earth would you need persistence? Well, I'm glad you asked. There indeed happens to be a somewhat unique, albeit infrequent use case where two different servers need to persist on YOUR IP address. The classic example is a site that requires federated authentication, where the service provider (SP) generates a token (perhaps a SAML auth request) and inside of that request the SP has embedded the client IP. The client receives this message and is redirected to the IdP to authenticate. But in this case the client is talking to the outside world through a forward proxy, and outbound source NAT (SNAT) could be required in this environment. That means there's a potential that the client IP address as seen from the two remote servers could be different. So if the IdP needs to verify the client IP based on what's embedded in the authentication request token, that could possibly fail. The good news here is that federated authentication doesn't normally require client IP verification, and there aren't many other similar use cases, but it can happen. The F5 BIG-IP, as with ANY proxy server, load balancer, or ADC device, clearly supports server affinity, and in a highly flexible way. But, as with ANY proxy server, load balancer, or ADC device, that doesn't apply to SNAT addresses. Nevertheless, the F5 BIG-IP can be configured to do this, which is exactly what this article is about. We're going to flex some BIG-IP muscle to derive a unique and innovative way to enable outbound SNAT persistence. What we're basically talking about is ensuring that a single internal client persists a single outbound SNAT IP address, when and where needed, and as long as possible. It's important to note here that we're not really talking about persistence in the same way you think about load balanced server affinity. With affinity, you're stapling a single (remote) client "session" to a single load balanced server. With SNAT persistence, you're stapling a single outbound SNAT IP to a single internal client so that all remote servers see that same source address. Same-same but different-different. To do this we'll need a SNAT pool and an iRule. We need the SNAT pool to define the SNAT addresses we can use. And since SNAT pools don't provide a persistence option like regular pools do, we'll use an iRule to provide the stickiness. It's also worth noting here, again since we're not really talking about load balancing stickiness, that the IP persistence mechanism in the iRule may not (likely will not) evenly distribute the IPs in the SNAT pool. Your best bet is to provide as many SNAT pool IPs as possible and reasonable. The good news here is that, because you're using a BIG-IP, you can define exactly how you assert that IP stickiness. In most cases, you'll probably just want to persist on the internal client IP, but you could also persist on: Client source address and remote server port Client source address and remote destination addresses Client source, day of the week, the year+month+day % mod 2, a hash of the word-of-the-day...and hopefully you get the idea. Lot's of options. To make this work, let's start with the SNAT pool. Navigate to Local Traffic -> Address Translation -> SNAT Pool List in the BIG-IP and click Create. In the Member List section, add as many SNAT IPs as you can afford. Remember, these are going to be IPs on your outbound VLAN, so in the same subnet as your outbound VLAN self-IP. Figure: SNAT pool list You don't need to assign the SNAT pool to anything directly. The iRule will handle that. And now onto the iRule. Navigate to Local Traffic -> iRules -> iRule List in the BIG-IP, and click Create. Copy the following into the iRule editor: when RULE_INIT { ## This iRule should be applied to your SSLO intercaption rule ending with in-t-4. catch { unset -nocomplain static::snat_ips } ## For each SNAT IP needed define the IP versus dynamically looking it up. ## These need to be in the real SNAT pool as well so ARP works. set static::snat_ips(1) 10.1.20.50 set static::snat_ips(2) 10.1.20.51 set static::snat_ips(3) 10.1.20.52 set static::snat_ips(4) 10.1.20.53 set static::snat_ips(5) 10.1.20.54 ## Set to how many SNAT IPs were added set static::array_size 5 } when CLIENT_ACCEPTED priority 100 { ## Select and uncomment only ONE of the below SNAT persistence options ## Persist SNAT based on client address only snat $static::snat_ips([expr {[crc32 [IP::client_addr]] % $static::array_size}]) ## Persist SNAT based on client address and remote port #snat $static::snat_ips([expr {[crc32 [IP::client_addr] [TCP::remote_port]] % $static::array_size}]) ## Persist SNAT based on client address and remote address #snat $static::snat_ips([expr {[crc32 [IP::client_addr] [IP::local_addr]] % $static::array_size}]) } Let's take a moment to explain what this iRule is actually doing, and it is fairly straightforward. In RULE_INIT, which fires ONCE when you update the iRule, the members of the defined SNAT pool are read into an array. Then a second static variable is created to store the size of the array. These values are stored as static, global variables. In CLIENT_ACCEPTED we set a priority of 100 to control the order of execution under SSL Orchestrator as there is already a CLIENT_ACCEPTED iRule event on the topology (we want our new event to run first). Below that you're provided with three choices for persistence: persist on source IP only, source IP and destination port, or source IP and destination IP. You'll want to uncomment only ONE of these. Each basically performs a quick CRC hash on the selected value, then calculates a modulus based on the array size. This returns a number within the size of the array, that is then applied as the index to the array to extract one of the array values. This calculation is always the same for the same input value(s), so effectively persisting on that value. The selected SNAT IP is then fed to the 'snat' command, and there you have it. As stated, you're probably only going to need the source-only persistence option. Using either of the others will pin a SNAT IP to a client IP and protocol port (ex. client IP:443 or client IP:80), or pin a SNAT IP to a specific host (ex. client IP:www.example.com), respectively. At the end of the day, you can insert any reasonable expression that will result in the selection of one of the values in the SNAT pool array, so the sky is really the limit here. The last step is easiest of all. You need to attach this iRule to your SSL Orchestrator topology. To do that. navigate to SSL Orchestrator -> Configuration in the UI, select the Interception Rules tab, and click to edit the respective outbound interception rule. Scroll to the bottom of this page, and under Resources, add the new iRule to the Selected column. The order doesn't matter. Click Deploy to complete the change, and you're done. You can do a packet capture on your outbound VLAN to see what is happening. tcpdump -lnni [outbound vlan] host 93.184.216.34 And then access https://www.example.com to test. For your IP address you should see a consistent outgoing SNAT IP. If you have access to a Linux client, you can add multiple IP addresses to an interface and test with each: ifconfig eth0:1 10.1.10.51 ifconfig eth0:2 10.1.10.52 ifconfig eth0:3 10.1.10.53 ifconfig eth0:4 10.1.10.54 ifconfig eth0:5 10.1.10.55 curl -vk https://www.example.com --interface 10.1.10.51 curl -vk https://www.example.com --interface 10.1.10.52 curl -vk https://www.example.com --interface 10.1.10.53 curl -vk https://www.example.com --interface 10.1.10.54 curl -vk https://www.example.com --interface 10.1.10.55 And again there you have it. In just a few steps you've been able to enable outbound SNAT persistence, and along the way you have hopefully recognized the immense flexibility at your command.
Outbound SNAT for servers: Destination Net Prohibited
Hi, Probably something simple ... I am trying to set up outbound connections for servers behind my F5 LTM. My assumption was that an outbound SNAT (using auto map)as per the configuration guides would accomplish this. Unfortunately not. When I do a test ping I get the message back from the Big IP: Destiantion Net Prohibited: When I configure a static NAT for a particular server everything is fine. The configuration guide does not mention any additional configuration required for this outbound snat scenario. I believe that NAT or SNAT should be sufficient to allow traffic through the LTM. For NAT this is the case. In the end I have created a "Forwarding IP" Virtual server for all source IPs and I have bound that to my internal interface. The Virtual server is suing "auto map" as well for source IP address translation. I would prefer to use the outbound SNAT and not the Virtual server. If someone could help identify the issue, I would appreciate it. Many thanks,
Preserve original source IP with SNAT for SMTP
Hi guys, Reading through various posts here on devcentral I have a feeling I will not be able to achieve what I want but I rather ask again. Our topology looks like: source -> firewall -> F5 LTM -> firewall -> router -> backend servers I am trying to load balance SMTP but the server guys need to see the original source IP in order to allow or deny sending emails. The problem is that I need to work with SNAT because the backend servers are far from the LB, behind another firewall and router. Their default gateway must be the one of the router. If I keep the original source IPs, I would face asymmetric routing and the some firewall on the way back would kill the session. We checked the backend SMTP server configuration and there is no other way to allow/deny sources there except of the IP addresses. So can I load balance SMTP traffic with SNAT while somehow be able (on the backend server) to tell what was the original source IP? Thanks.
Use VIP address as source
Hello everyone, How can I allow the VIP IP as a source when the Pool Member iniciates the connection on a specific port? I tried with a NAT but it will NAT all the traffic I need only to NAT with when the pool member iniciates the traffic in a specific port. (Actually the NAT didn't work, I have a capture on a FW and the connection is using the self IP of the F5). I tried with a SNAT and SNAT Pool but it doesn't worked either, I can see the self IP in the FW when the server iniciates the traffic. I also tried with an iRULE, something like this: when CLIENT_ACCEPTED { if {[TCP::local_port] == 2196} { snatpool SNAT_POOL_TEST } pool airwatch-AWCM-2001 } Thank in advance for your responses. Regards, Jose Charpentier F
F5 LTM SNAT: only 1 outgoing connection, multiple internal clients
I have an F5 LTM SNAT configured: ltm snat /Common/outgoing_snat_v6 { description "IPv6 SNAT translation" mirror enabled origins { ::/0 { } } snatpool /Common/outgoing_snatpool_v6 vlans { /Common/internal } vlans-enabled } ... with a translation configured as: ltm snat-translation /Common/ext_SNAT_v6 { address 2607:f160:c:301d::63 inherited-traffic-group true traffic-group /Common/traffic-group-1 } ... with snatpool configured as: ltm snatpool /Common/outgoing_snatpool_v6 { members { /Common/ext_SNAT_v6 } } ... and finally, with the SNAT type set to automap: vs_pool__snat_type { value automap } The goal is to achieve a single Diameter connection (single source IP, port) between F5 and the external element, while internally multiple Diameter clients connect via F5 to the external element: However, what ends up happening with this SNAT configuration is that multiple outgoing Diameter connections to the external Diameter element are opened, with the only difference between them being the source port (source IP, destination IP and port remained the same). The external element cannot handle multiple connections per the same origin IP and the same Diameter entity (internal clients are all configured to use the same Origin-Host during the Capabilities Exchange phase). Is there a way to configure F5 to funnel all the internal connections into a single outgoing one?
iRule SNAT for multiple ISP
Hi, I tried to configure an iRule to SNAT specific LAN to a specific ISP (wan link). When I bind this iRule to my default VS (in fastL4) the iRule doesn't match when I generate traffic from my lan. I don't know if my iRule is good... : when CLIENT_ACCEPTED { set my_ip [IP::client_addr] if { [IP::addr [IP::client_addr] equals X.X.X.X/26] or [IP::addr [IP::client_addr] equals Y.Y.Y.Y/26]} {snat Z.Z.Z.Z pool default_gw_pool } else {snatpool snat_pool-CLD_ALL pool default_gw_pool } } Some have an idea?inline configuration
Hi, I have configuration: NET => FW => F5 => SRV I have VS1 which forwards traffic to SRV (no SNAT used, not possible to do XFF so source address of client is seen). F5 is def gw for SRV. On F5 there is also forwarding IP VS 0/0 and def route to FW. FW also have static route for SRV subnet poiting to F5. Questions: 1. Client from net goes to VS1 (SNAT off) is redirected to SRV (source address is seen, destination nat is in place to pass traffic to SRV). I assume that return traffic from SRV is hitting VS 0/0 (am I right?) VS 0/0 have snat off. And I also assume that source address of SRV is changed to VS1 IP (am I also right?). If not, should I do some SNAT on VS 0/0? Second example. When server is originating connection to NET it hits VS 0/0, is that right? No SNAT is configured so source address of server is seen outside? The route on FW pass traffic back to SRV via F5. If point 1 is true (so when return traffic is automatically SNATed back to VS1 IP) what determines that traffic is SNATed or not? Is it previously created session/entry for DNAT when traffic originating from Net hits VS1?
