VRID IP changes during session causing security error

Community Forum Forums Thunder and AX Series General VRID IP changes during session causing security error

This topic contains 7 replies, has 3 voices, and was last updated by avatar PhillipB 2 weeks, 4 days ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #16800
    avatar
    nthomasCmet
    Member

    Hi All,

    sorry if I am not talking much sense, but can provide more detail if needed.

    we got a virtual server rule setup to use a specific VRID which has an IP range from 71 to 90.

    we have a HR website, where users can apply online for jobs, and during the sessions (while filling in the forms) the end user will bounce between various VRID IP addresses causing a Security error on the website and the session to timeout. having to start filling in the forms all again.

    What we would like is for the end users to not bounce between VRID IP addresses and keep the same VRID IP connection for the whole session.

    any help / advice welcome.

    #16801
    avatar
    diederik
    Member

    Hello,

    The only way for client to bounce between different IP addresses for the same service (hostname), is if you have set it up in such a way that the DNS returns different IP addresses.
    Of if the form uses different hostnames for certain requests.

    Can you explain a bit more about your setup?

    Are you using the 71-90 IP range in a way that is linked to the same hostname?
    Or does the process use different hostnames which need to get linked to the same IP address?

    Greetings,

    Diederik

    #16802
    avatar
    nthomasCmet
    Member

    Hi

    when I say VRID I mean Source NAT Pool.
    SNAT-VRID-2 x.x.x.71 x.x.x.90 /24

    and we have a ADC>>SLB>>Virtual Servers
    using a virtual port of 443 and 80
    and a source NAT Pool of SNAT-VRID-2

    we can replicate this issue on our test environment , and that is using 1 server to do all the work.

    I can see in the tomcat log:

    X.X.x.72 – – [06/Jun/2019:10:34:31 +0100] “POST /test/wrd/run/ETREC105GF?USESSION=EA1775581D0241EBABD59E5B59F741DF&WVID=4385410jIi&LANG=USA HTTP/1.1” 200 22620

    X.X.x.71 – – [06/Jun/2019:10:34:36 +0100] “GET /test/wrd/run/ETREC107GF.open?VACANCY_ID%3d606796EbyI%1BUSESSION=EA1775581D0241EBABD59E5B59F741DF&WVID=4385410jIi&LANG=USA HTTP/1.1” 200 20419

    in Userver log:

    WRACT: 06/06/2019 10:35:24 9292GP0D ETREC111GF OPEN Page ID:365246COhi Vacancy ID:6796EbyI Form ID:6667COhi Session:1775581D0241EBABD59E5B59F741DF
    ETREC111GF – L_GET_STATE – SECURITY ERROR 06/06/2019 10:35:30
    T_CLIENT_IP=x.x.x.72, T_LOGIN_IP=x.x.x.71
    T_PROXY_CLIENT_IP=, T_LOGIN_PROXY_IP=
    T_USER_AGENT=Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko,
    T_LOGIN_AGENT=Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
    COMP=ETREC111GFSESSION=EA1775581D0241EBABD59E5B59F741DFSERVERVARIABLES=SERVER_PORT=80 PATH_INFO=/run/ETREC111GF AUTH_TYPE= SERVLET_PATH=/wrd REMOTE_USER= REMOTE_HOST=x.x.x.72 REMOTE_ADDR=x.x.x.72 SERVER_NAME=test.removed.co.uk REQUEST_URI=/test/wrd/run/ETREC111GF QUERY_STRING=USESSION=EA1775581D0241EBABD59E5B59F741DF&WVID=4385410jIi&LANG=USA CONTENT_TYPE=application/x-www-form-urlencoded SERVER_PROTOCOL=HTTP/1.1 CONTENT_LENGTH=4207 SERVER_PORT_SECURE=0 PATH_TRANSLATED=D:\Home\db\test\webapps\run\ETREC111GF REQUEST_METHOD=POSTSESSIONCOOKIE=falseREQUESTTYPE=staticEXPECTEDRESPONSE=fullpage
    ETREC111GF – L_SHOW_STOP_PAGE – SECURITY ERROR 06/06/2019 10:35:30
    P_MSG_CODE=E0226SECURITY

    #16803
    avatar
    diederik
    Member

    Since you have a pool of IP addresses for NAT, it is hard to make sure all client connections get NAT-ed with the same source IP from the pool.
    Especially since many clients will be using the same NAT Pool and thus source IP’s.

    If you want to check the client IP address for security reasons, it would be better to check the real source IP address of the client.

    If you set the A10 as the gateway for the backend servers, you do not need to use SNAT.
    Or if that is not possible, can you have the security check look at a header?
    You can then have the A10 set a “X-Forwarded-For” or “X-Client-IP” with the originating source IP address it sees, this will stay the same between all requests.

    #16804
    avatar
    nthomasCmet
    Member

    Hi Diederik

    Thank you for your quick replies and assistance. I am totally new to A10 system, where would I create this “security check” for the header?

    is it an AFLEX script?

    thanks again

    #16805
    avatar
    diederik
    Member

    Hello,

    With security check, I meant the check you do on the backend server.
    Your systems seems to check the IP address of the client when they authenticate, and all subsequent requests from that same client need to come from the same source IP.

    Can you change the security check your server does in such a way that it looks at a header?

    The “X-Client-IP” or “X-Forwarded-For” header can be set in a HTTP-Template which needs to be bound to your HTTP/S Virtual Service.
    The option is called “Client IP Header Insert” and requires you to add the name of the header… “X-Forwarded-For” is kinda the de facto standard for this.
    I would also set the “Replace Existing Header” to make sure it can not be spoofed.
    (if down the chain there is a system which also sets the header, it most likely also changes the source IP address… so for your security system it would not make the system any less secure)

    #16806
    avatar
    nthomasCmet
    Member

    Hi

    thank you for your explanation, I will have a chat with the developers.

    #16807
    avatar
    PhillipB
    Member

    @nthomascmet — do you by chance have the ip-rr configured in the ip nat pool SNAT-VRID-2??
    That is the behavior that your logs seem to be exhibiting.

    If so, I suggest removing the ip-rr statement and trying again.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

Comments are closed.