empty character in policy conditions
Hello good, I have changed iRule to policies, I have an HTTP-->HTTPS redirection rule that is formed as follows. when HTTP_REQUEST { if { ( [HTTP::uri] equals "" ) or ( [HTTP::uri] equals "/") } { HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri] } According to that iRule, whether the uri begins with / or ' ', it redirects me to HTTPS But when it comes to passing it to policies, I can't find the way to indicate the empty character. Does anyone know how to indicate it? I have already tried to put ' ' and add it but it doesn't work. Greetings and thanks.
Three Ways to Specify Multiple Ports on a Virtual Server
Last month, community member Racquel Mays asked for some assistance with creating a local traffic policy to apply to a virtual server to listen only on specific ports. I knew of only two obvious ways to solve that problem until fellow F5er Simon Blakely dumped a whole bowl of awesome sauce on us. In this article, I’ll cover not one way, not two ways, but also a completely new to me third way: traffic matching criteria. Before jumping into the specifics, I want to clarify something in Racquel’s question. If a virtual server is listening on port 0, then it is listening on all ports, even if you then, after the fact, filter them down to a select interesting list. For details on packets/flows in the BIG-IP system, check out my Lightboard Lesson on that. Option 1 - Use an iRule This is almost always my first thought. Mostly because I love iRules and I’m comfortable with them. But iRules aren’t always the best option, so it’s a good idea to evaluate from an operational perspective as well as performance. If both are negligible, this solution is very simple to implement, easily understood, and because of the simplicity, fairly performant when compared with the next option. ltm rule allports_irule { when CLIENT_ACCEPTED { switch [TCP::local_port] { 80 - 8080 { pool nerdlife_pool } default { reject } } } } In this iRule, when the TCP connection is established, the local port (BIG-IP side of the client connection) is evaluated and if it handled by a switch case, the pool is selected. The same pool is not required for each service but is used in this example. Any port that is not specified in the switch statement will result in a rejected TCP connection to the client. Option 2 - Use a Local Traffic Policy For a growing set of services, iRules can be retired and polices can be used in their place. They are built-in to TMOS and (unless you call Tcl from them) do not require the Tcl interpreter and thus will likely be more performant. However, if you have to split functionality between iRules and policies on a single application service, my preference is to keep the logic in one place so operational complexity is reduced. ltm policy allports_policy { controls { forwarding } requires { tcp } rules { tcp-80 { actions { 0 { forward client-accepted select pool nerdlife_pool } } conditions { 0 { tcp client-accepted port local values { 80 } } } } tcp-8080 { actions { 0 { forward client-accepted select pool nerdlife_pool } } conditions { 0 { tcp client-accepted port local values { 8080 } } } ordinal 1 } tcp-all-else { actions { 0 { shutdown client-accepted connection } } conditions { 0 { tcp client-accepted port local not values { 80 8080 } } } ordinal 2 } } status published strategy first-match } The policy is a tad verbose, no? This is due to the hierarchical nature of policies, having the policy root details like publications status and matching strategy, and then the rules for conditions and actions. Here in the text it’s easy to spot the condition of the local TCP port, but in the GUI, you have to select that in a hidden options menu. That got me for a hot minute while trying to make the policy work. In any event, options one and two are functionally equivalent when applied to a virtual server listening on port 0 with a TCP profile applied, so either approach is a good option depending on your business and technical standards for how BIG-IP objects are used. Option 3 - Traffic Matching Criteria I wanted to write the article when Simon shared this solution so I could be cool by saying “I was today years old when I learned you could do this” but alas, priorities! In this solution, there are two differences in this approach from the other two: multiple addresses as well as multiple ports are supported, so you can scale without requiring configuring additional virtuals there is no way in the criteria to map service port -> pool, so if you need that beyond a default pool in the virtual config, you're going to need an iRule or policy anyway You can find and create address and port lists in the GUI under Main->Shared Objects. I started my work in tmsh for this article and the lists are in the tmsh /net namespace, so I had to hunt for these as I was looking for them in the GUI’s Network section. You’ll need those to create your own traffic-matching-criteria object, but you can’t do that directly in the GUI. It is done on your behalf when you specify the lists in the creation of a virtual server. This will create this traffic-matching-criteria object in tmsh: ltm traffic-matching-criteria vip3_tmc_VS_TMC_OBJ { destination-address-inline 0.0.0.0 destination-address-list dal1 destination-port-list dpl1 protocol tcp source-address-inline 0.0.0.0 } It appends _VS_TMC_OBJ to the virtual server name as the object name it creates. The GUI also specifies the destination-address-inline and source-address-inline arguments, but I didn't need those in my object for it to work. That said, if the GUI selects them, there's probably a good reason so maybe default there as well and adjust as necessary in testing. Do It Yourself You already have the iRule and policy you need to test in your own lab above, now all you need are the other the virtual servers for options one and two and then the lists, traffic-matching-criteria, and virtual for option three. You can create all those with the tmsh commands below. My client-side lab network is 192.168.102.0/24 and I have a working pool (nerdlife_pool) on the server-side. You’ll need to swap those values out for your environment. # With iRule - Address 192.168.102.61 # tmsh create ltm virtual vip1_irule destination 192.168.102.61:0 ip-protocol tcp profiles add { http { } tcp { } } rules { allports_irule } source-address-translation { type automap } # With Policy - Address 192.168.102.62 # tmsh create ltm virtual vip2_policy destination 192.168.102.62:0 ip-protocol tcp profiles add { http { } tcp { } } policies add { allports_policy { } } source-address-translation { type automap } # With Matching Criteria - Address 192.168.102.63 # # If you do this in the GUI, it creates the traffic-matching-criteria for you, but no control of naming or modification that way tmsh create /net address-list dal1 addresses add { 192.168.102.63 } tmsh create /net port-list dpl1 ports add { 80 8080 } tmsh create /ltm traffic-matching-criteria tmc1 protocol tcp destination-address-list dal1 destination-port-list dpl1 tmsh create /ltm virtual vip3_tmc ip-protocol tcp traffic-matching-criteria tmc1 source-address-translation { type automap } pool nerdlife_pool profiles add { tcp http } You should now have three virtual servers with like functionality. Test Results Now that everything is configured, let’s test it out! We’ll test the two ports we want to answer, 80 and 8080, and then a third port we don’t, 8081. We should get an “achievement: unlocked” on the first two and a connection reset on the third. # Test results - iRule rahm@FLD-ML-00029232 ~ % curl http://192.168.102.61/a achievement: unlocked rahm@FLD-ML-00029232 ~ % curl http://192.168.102.61:8080/a achievement: unlocked rahm@FLD-ML-00029232 ~ % curl http://192.168.102.61:8081/a curl: (56) Recv failure: Connection reset by peer # Test results - Policy rahm@FLD-ML-00029232 ~ % curl http://192.168.102.62/a achievement: unlocked rahm@FLD-ML-00029232 ~ % curl http://192.168.102.62:8080/a achievement: unlocked rahm@FLD-ML-00029232 ~ % curl http://192.168.102.62:8081/a curl: (56) Recv failure: Connection reset by peer Test results - TMC rahm@FLD-ML-00029232 ~ % curl http://192.168.102.63/a achievement: unlocked rahm@FLD-ML-00029232 ~ % curl http://192.168.102.63:8080/a achievement: unlocked rahm@FLD-ML-00029232 ~ % curl http://192.168.102.63:8081/a curl: (7) Failed to connect to 192.168.102.63 port 8081: Connection refused The traffic-matching-criteria virtual didn't reset like the other two explicitly configured to do so, but it did refuse the connection all the same. I couldn't walk away from that without understanding why so I fired up Wireshark and took a tcpdump capture to investigate. What’s happening here is that with the iRule and policy solutions, we are acting at the CLIENT_ACCEPTED event, which means the TCP session has already been established and the HTTP request is in flight. So you see two TCP resets for each of the curl requests to 192.168.102.61:8081 and 192.168.102.62:8081, the first to the rejected TCP port, and the second to the HTTP request, which because it was already in flight, arrived even before the first TCP reset was sent. With the traffic-matching-criteria solution, it’s all wrapped up before a connection is even established so only the one reset message. That results in greaterefficiency with local resources. Conclusion I say this a lot but I’m always excited to learn new things, particularly new ways of doing something I’ve done differently for years. If you’ve ever watched a master craftsman work, they have their favorite tools, but they have specialty tools as well for situations that call for it. I liken discoveries like this to that scenario. I’m not sure how many use cases I’d find for the traffic-matching-criteria that wouldn’t also rely on a policy and/or iRule, but I’m happy to now know that it exists just in case. How many of you knew about this and didn’t tell me? Drop me a comment below!BIG-IP Solutions: Simple URL Redirects
Check out our "BIG-IP Solutions" series where we will dive into all kinds of cool features related to the BIG-IP. In this edition, I'll take a look at simple URL redirects where I'll show how to redirect traffic from one web page to another. Many people use iRules for URL redirects, but the BIG-IP offers policies to do this for you. Policies are faster than iRules, they are easier to manage, and you don't have to know the exact scripting language code to use them. Check out this video to learn more about how to redirect URLs with policies!
Managing many WAF policies
Hello guys My question is more likely to be administrative question, and less technical. And I need some advices on this. We're managing so many WAF policies for so many websites. About 50+ policies. And each website has his own developers. So each time there is WAF suggestions on each policy we contact each developer to tell us if we should accept those suggestions or discard them. And this is a lot of work. Those developers has no access to the F5 machine and even have no clue how to manage it. I thought about creating an FTP server where I can upload those suggestions there and give access to developers and then they will update me which suggestions to approve and which not. But I'm not sure if this is creative solution, plus there will be a lot of work of exporting and uploading suggestiins. Has any one faced the same thing and came up with a creative solution and made it easy to manage this amount of policies with those amount of developers?What do you think about this?
LTM Policy with Rewrite profile forward to specific Node
The issue I am currently facing is in the common partition I have a profile rewrite and an LTM policy in place working perfectly and has no issues. I have tried to replicate this in a different partition with the exact same steps and it is not working. We have a virtual server: VS_Azure1.aeltc.com_10.205.1.xxxabc.aeltc.com10.205.1.xxx443 (HTTPS)StandardEdit...DMZ And we have a pool: pool_abc.aeltc.com3DMZ In this pool we have 3 different nodes ( running 3 different services ) The profile rewrite looks like this: Client uri: https://abc.aeltc.com/aegis/tt/api/ > server uri: https://ae-iapp01-tt.office.aeltc.org/AEGIS10/api/ Client uri: https://abc.aeltc.com/catering/tt/api/ > server uri: https://uniwareintegration-tt.office.aeltc.org/api/ The above are 2 examples, so the LTM policy I have tried to configure is: If when browsing to abc.aeltc.com they add /aegis/tt/api/ then send the traffic to node one always. If when browsing to abc.aeltc.com they add /catering/tt/api/ then send the traffic to node two always. I have attempted to do this via LTM however the policy isn't working it still load balances via the pool? Any help would be deeply apricated.
Source IP redirect, change host, uri and change to 443
I'm using BIG-IP LTM I have a VIP on port 4001 taking external connections, this goes to a pool with a client SSL cert. I am trying to "route" to a different destination based on the source IP address. However, I need to manipulate the uri as well. I have tried this via an iRule, but looking at the forum people are saying just use the policies section of the F5. I am a network engineer by trade and I very rarely get this deep into LTM. Please can you assist? I have outputs from what I have tried below. I have run packet captures and see that the request does forward, but in plain text (iRule output), so I have tried to encrypt it before sending it to the destination, but I don't think I'm doing it right. pool_RTS_Azure = dev.api.comany.com:443 pool_RTS_4001 is the default pool pool_RTS is the same as pool_RTS_4001
ASM Policy error importing on Version 14
Hi, I have 25 asm policies in Version 13 BIG-IP. When importing them all in to a new instance of BIP-IP 14, 2 policies give the same error and do not import. The error reads: Can't call method "new" on an undefined value at /usr/local/share/perl5/F5/ASMConfig/Entity/Suggestion.pm line 279. Is there something in the XML file that I can adjust/remove in order to correct this? Thank youLTM Tfaffic Policies via iControlRest
Prior to v12.1.0 I had an automation script which we run in batches of dozens to hundreds of VIP, Pool, Profile, Policy, etc creations. The script utilizes the Rest interface to create Policies and after Vip creation, it applies the policies. Much to my surprise after our network team upgraded some of our F5s to v12.1.0 last week, the Policy creation broke. I explored this in the GUI and see the problem. There is now a "draft" phase introduced before published policies. I managed to tinker with my powershell and successfully create a new "draft" policy. However, I cannot successfully get the draft policy published via the Rest interface. Does anyone know how this can be accomplished programmatically? Using the GUI is not a viable option when I am building out hundreds of Policies at a time.
