Forum Discussion
Hello Santhosh.
Try this code instead:
if { not [class match [IP::client_addr] contains XYZ_group] } {
HTTP::respond 301 Location "http://rextrum.com/xyz"
}
KR,
Dario.
for some reason it's not liking the contains with in that. So I used equals but it's failing on redirection where it's throwing a error page.
- Apr 06, 2020
Sure, equals is OK.
when HTTP_REQUEST { if { not [class match [IP::client_addr] equals XYZ_group] } { HTTP::respond 301 Location "http://example.com/xyz" } }
Test it from my lab and it's working fine.
I think your issue is in your data-group. Could you share the next command output (from TMSH)?
list ltm data-group internal XYZ_group
KR,
Dario.
- SanthoshApr 07, 2020Nimbostratus
ltm data-group internal XYZ_group {
records {
10.0.0.0/8 { }
}
type ip
}
- SanthoshApr 07, 2020Nimbostratus
Dario,
one more thing I forgot to mention is the Virtual server is a HTTPS on and the redirection site is HTTP. Does that causes any issue?
- Apr 07, 2020
Hello Santhosh.
Not necessary. The best way to see if the iRule is working is to check using CLI instead of browser. Try this command and show us the output (remember to use a client with an IP not included in the data-group):
curl -skv https://<your_vs_ip>:port
KR,
Dario.
- SanthoshApr 08, 2020Nimbostratus
I have changed the hostname in the result
* Rebuilt URL to: https://example.org/
* Trying 192.187.145.2...
* Connected to example.org (192.187.145.2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=ca; L=sacramento; O=Company; OU=NMS; CN=example.org
* start date: Jul 2 00:00:00 2018 GMT
* expire date: Jul 5 12:00:00 2020 GMT
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Thawte RSA CA 2018
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: example.org
> User-Agent: curl/7.47.1
> Accept: */*
>
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
* Closing connection 0
- Apr 08, 2020
The issue is not in the iRule/Data-group. It's in other part of your configuration.
1) Could you confirm that your VS can operate regularly in case of matching the data-group (the other scenario)?
2) Could you share your VS/client-ssl configuration?
tmsh list ltm virtual <VS_name> tmsh list ltm profile client-ssl <Client-ssl_name>
KR,
Dario.