SNAT is not forwarding traffic towards Pool
VIP, Self IP and SNAT are in same VLAN but Pool member is in different VLAN. Pool is reachable from Self IP. VIP and Pools are up, SNAT pool added in VIP. Traffic is visible on VIP from internet but SNAT is not forwarding traffic towards pool. pls suggest on this ? Internet >> WAF VIP (vlan 123) >> SNAT (vlan 123) or Self IP (vlan 123) >> Pool (vlan 456)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.
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, Fabian
SNAT 1:1 - Map client public IP to nat pool IP
I have a situation were we have a BIG IP F5 load balancer in front of a MS RRAS server acting as a VPN concentrator. When a user connects to the VPN the radius auth is proxied through a Cisco ISE instance to tie the user to an IP address, this allows us to create identity based firewall rules. The problem is at the moment RRAS is seeing all clients coming from the load balancer because we have SNAT enabled. In Cisco ISE you can only have one active session per endpoint ID and all users are comming through as the same endpoint ID (the load F5's internal SNAT address). So my question, it is possible to setup SNAT in a way that each client will come from a unique SNAT address from a SNAT pool?
Wildcard in SNAT
I want configure an snat translation to change the source IP ltm tries to connect *.f5.com(say). Can I use wildcard in snat? If not, is there any other solution to this? Current Scenerio: LTM(src-1.1.1.1) -To- *.f5.com [Takes 0.0.0.0/0] --> FW1 [Takes 0.0.0.0/0] --> Internet Issue: FW1 does't support *, can't allow access only to *.f5.com. Proposed: LTM(src-1.1.1.1) -To- *.f5.com [Takes 0.0.0.0/0] --> SNAT(1.1.1.1->2.2.2.2) -To- *.f5.com [Takes 0.0.0.0/0] -->FW1[Allow all https for source 2.2.2.2] [Takes 0.0.0.0/0] --> Internet OR LTM(src-1.1.1.1) -To- *.f5.com [Takes 0.0.0.0/0] --> SNAT(1.1.1.1->2.2.2.2) -To- *.f5.com [Takes 0.0.0.0/0] -->FW1[PBR to FW2 that supports * for source 2.2.2.2] [Takes 0.0.0.0/0] --> Internet ORSNAT irule doesn't match for a FastL4 VS for an IPSEC VPN
Hi everybody, I have a problem to bring up an IPSEC Tunnel between 2 firewall with one of them behind an F5 BIGIP. What I did : Create a VS FastL4 (Source Address 0.0.0.0/0, Destination Address my_public_ip_used_for_the_vpn, Service port All_Ports, Protocol All, Source Address Translation NONE). For the SNAT I tried to use a SNAT POOL For the SNAT I tried to use an iRule : when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 10.199.0.1/32] } { snat X.X.X.X.85 nexthop X.X.X.X.1 log local0. " -- SNAT VPN IPSEC S2S -- [clientside {IP::remote_addr}]:[clientside {TCP::remote_port}] to [clientside {IP::local_addr}]:[clientside {TCP::local_port}]" } } For the SNAT I tried to use GUI : In all case the F5 doesn't take my SNAT rule and the traffic take another public IP. On the peer device (which is not behind an F5) I have a log "Asymmetric Routing". It's normal because he tries to establish the tunnel with an IP and there is another IP that respond to him. On the F5 I can see it on the logs 16:30:36.409542 IP Y.Y.Y.Y.isakmp > X.X.X**.85**.isakmp: isakmp: phase 1 I ident 16:30:51.939720 IP 10.199.0.1.isakmp > Y.Y.Y.Y.isakmp: isakmp: phase 1 I ident 16:30:51.939732 IP X.X.X**.251**.20251 > Y.Y.Y.Y.isakmp: isakmp: phase 1 ? ident The peer device seems to successfully contact my firewall on Y.Y.Y.85 but the F5 respond with the Y.Y.Y.251 Is there anything that I forgot in the configuration?
SNAT node to VIP iRule
Hey everyone - V13 All nodes point to F5 as default gateway Forwarding IP VIP 0.0.0.0 We would like outbound connections from each node to SNAT to it's respective VIP IP. Does someone have a configuration/iRule that will work for this? Also, if there was a way to use the same iRule for each VIP (without IP changes), that would be ideal. So based on configuration below, how can node1 (10.4.55.10) SNAT from existing VIP (10.3.0.10) ? ltm virtual VIP1 { destination 10.3.0.10:5986 ip-protocol tcp mask 255.255.255.255 pool POOL1 profiles { tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } ltm pool POOL1 { members { NODE1:5986 { address 10.4.55.10 session monitor-enabled state up } } monitor tcp_half_open } ltm virtual vs_0.0.0.0_any { destination 0.0.0.0:any ip-forward mask any profiles { fastL4 { } } source 0.0.0.0/0 translate-address disabled translate-port disabled } net route external_default_gateway { gw 10.3.0.1 network default } net self FLOATING_IP { address 10.4.55.1/24 allow-service all floating enabled traffic-group traffic-group-1 unit 1 vlan NODE1_VLAN }
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?Please validate iRule to Load balance the traffic based on SNAT.
Hello Folks, I need your help by verifying my iRule, responsible to SNAT the traffic generated from one Site (B) and going to another site (A), and should select specif pool to communicate further. when CLIENT_ACCEPTED { if { [IP::addr [IP::remote_addr] equals 1.1.1.0 mask 255.255.255.0] } { snat 1.1.1.1 pool Test_Pool } else {pool Normal} } Brief information about customer setup. Client has 2 sites located on different geographic area. We are managing their network setup. Being an ISP, we are responsible to load balance all the traffic flowing between two sites. Now, they have configured their network in such a way, where SiteA should see only one specific IP address when SiteB tries to communicate with SiteA. At the same time, load balance should work for both the sites. Please feel free to reply if you need any further informaiton to verify the iRule or share a better one.Choose SNAT based on URL in HTTP_REQUEST
Hi, Due to lack of external IPs I have two URLs that are resolved to a single IP. This IP is further NATTED to an internal IP in my network (the one of a VS on F5). Based on URL in HTTP_REQUEST an iRule is sending traffic to a node in one of two networks: 10.0.0.32/27 (VLAN 1001) and 10.0.0.64/27 (VLAN 1002) when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { "*.url1.com*"{ node 10.0.0.83 80 log local0 "Redirected to live pool [HTTP::host]" } "*.url2.com*"{ node 10.0.0.41 80 log local0 "Redirected to live pool [HTTP::host]" } } } The VS has (now) has VLAN and Tunnel traffic enabled on VLAN 1002 and address 10.0.0.88 in it's SNAT pool list. Due to my DC design when a VS is in the same subnet as the node everything is perfect. When the subnet is different the traffic needs to go through same firewall couple of times and it makes any future troubleshooting difficult. What i would like to achieve is to force F5 to use a different SNAT address, depending on which URL it received the traffic. I tried adding VLAN 1001 to enabled VLANS in VS, adding address 10.0.0.60 to SNAT pool and adding a line: snat 10.0.0.60 to the second part of the iRule. Needles to say no luck, and so far only the works fine, and does not. I have version 12 if that's relevant.
