PFSense breaking Windows Server API calls
This is a very odd one but we have found an issue with PFSense and Windows Server 2008 & 2012 API calls. This bug only effects servers behind PFSense which are using Windows 2008 & 2012. It works fine on Windows 7 and all Linux distro's.
An example call is:
curl -k -i -H "Accept: application/json" -H "X-Application: <appkey>" -X POST -d 'username=test&password=test' https://identitysso.betfair.com/api/login
On linux it comes back with:
HTTP/1.1 200 OK
If we run it on windows it fails with a timeout error.
We can confirm the fault is with PFSense though as if we tick Disable all packet filtering, it works without error.
I would have thought it was a setting on the firewall directly except that we have tested it on a number of other platforms and it works without error. It also is not limited to just a single server as we currently have around 5 different windows servers all with the same error.
We have also used all the tools in the GUI to monitor the packets and they are all identical, we also ran WireShark on the server and again it looked the same. I think windows is dropping the packets which have been inspected via the firewall?
Has anyone got any idea on this one?
Have you disabled the windows firewall on all levels?
We have tested this with the Windows Firewall fully disable and also fully running but again it times out using both setups.
I am really out of ideas on this one, so any help would be great.
I get this
This code is called directly from the CURL command and is designed with other variables to be included within the call. I think its more to do with the way the command is being run and our firewall is working in transparent mode as well if this makes a difference?
KOM last edited by
our firewall is working in transparent mode as well if this makes a difference?
Transparent mode does not apply to the firewall. Are you running Squid proxy? That would go a long way to explaining why you'r having URL troubles.
No we are not running squid proxy at all.
Have you found the cause of this and a resolution? We have the exact same issue.
dennypage last edited by
If I'm going to shoot in the dark, I might as well shoot twice. :)