Forum Discussion
CirrostratusHTTP deny access troubeshooting
Hi, I just created one-armed setup for some testing in existing network topology. Scenario (Standalone VE 11.6): 1. All resources on let's say on 192.168.1.0/24, VLAN external, selfIP 192.168.1.10 2. Standard HTTP VS, http profile, SNAT Automap, no persistence, no other changes to defaults, VIP 192.168.1.20 3. Target server 192.168.1.100 (in fact its load balancer based on hproxy, application servers behind) 4. Pool with one member 192.168.1.100:80 5. Node with def icmp reporting status up 6. Pool member with def http reporting status up 7. Every piece displaying green dot status 8. Client PC with 192.168.1.200
Effect: 1. PC can access correct page with http://192.168.1.100 - direct connection to server 2. curl on VE can access http://192.168.1.100 - correct page returned 3. PC with http://192.168.1.20 is getting access denied page from the server
I would suspect some blocking set for seflIP address (source IP for packets because of Automap) but then curl should get the same error page (curl is as well using selfIP as source IP). Request are reaching server and correctly coming back to VE, but instead normal page, error page is displayed (not authorized to access this content or something similar).
I am puzzled, what can cause error page when accessing server via VS? Is there something obvious I should check? What steps/tools will be most appropriate to troubleshoot this issue?
Piotr
6 Replies
Brad_ParkerCirrus
I would recommend capturing a TCPDUMP of the request to and response coming from the server to verify the request from the PC client matches the request you are successfully sending via cURL and that the access denied response is coming from the application.
.tmsh tcpdump -s0 -ni :nnn host 192.168.1.100
dragonflymrHi,
Thanks but both direct requests to server from browser and curl are returning good result. Only request from browser to server via VS is returning deny page. I think that in this case maybe capturing requests from browser to VS and direct browser request or direct browser request and request from LTM to server could give some clue - what do you think?
Piotr
- Brad_Parker
Grabbing the packets from all conversations will definitely help identify the issue; PC to server, cURL to server, PC to VIP, and LTM to server. If the server is responding with a 403, it doesn't like something about the request. Just as a shot in the dark, do you have "Address Translation" checked on your VIP?
- dragonflymr
Hi, That was standard VS, so should have Address and Port translation checked. I have no access to the system right now to check as it was on some test system set at customer site. Anyway nothing except mentioned setting was modified from defaults when vs was created. Still what could be reason of denying page, customer claimed that there are no blocking measures set for the server - and it seems so as both curl and browser can access server when pointed directly. Anyway, thanks for help, when I will have chance to do dumps maybe something will clear up.
Piotr
- Brad_ParkerHave you confirmed weather they are getting a 403 or are they not getting a response? They are two very different things.
- dragonflymr
Can't right now. There was response as page with info was displayed in browser and customer confirmed that it's returned from server.
Piotr
