Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does this support non-HTTP traffic blocking? #18

Open
bganderson opened this issue Aug 17, 2018 · 1 comment
Open

Does this support non-HTTP traffic blocking? #18

bganderson opened this issue Aug 17, 2018 · 1 comment

Comments

@bganderson
Copy link

It's my understanding that the PA behind the ELB will not be able to see the original client IP (other than X-Forwarded-For for HTTP traffic), so is this solution only for HTTP based traffic or is there something I'm not understanding?

@vinayvenkat
Copy link
Contributor

Hi @bganderson Looks like you are talking about two different scenarios if I understand your question.

  1. So the architecture for using the ELB is primarily for HTTP/HTTPS traffic.
  2. To answer the second question, yes will be able to see the original client IP by using the XFF header. However, to enforce using the original IP from the XFF, you will need to map that IP into a userid field before setting up the policy.
    Hope this helps and apologies for the slow response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants