16
20.7 Legacy Series / Re: nginx auth issues with Exchange 2016/IIS 401 loop
« on: February 09, 2021, 06:54:53 pm »
I got it working! I had to turn off response and request buffering, and set the Maximum Body Size to 2G.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Attempting to ping the MAPI Mail Store endpoint with identity: xxxxx-9188-4474-9811-0ef5db77cf19@xxx.com:6001.
The attempt to ping the endpoint failed.
Additional Details
An RPC error was thrown by the RPC Runtime process. Error 1818 CallCancelled
RPC Status: 1818 CallCancelled
Timestamp: 2/9/2021 5:33:20 PM
Generating Component: 14 (WinHttp)
Status: 1818
Detection Location: 1390 (HTTP2ClientVirtualConnection__ClientOpenInternal10)
Flags: 0
Parameters:
30000
root@cerberus:~ # grep include /usr/local/etc/nginx/nginx.conf
include mime.types;
js_include /usr/local/opnsense/scripts/nginx/ngx_functions.js;
include http_post/*.conf;
# include nginx_web.conf;
include opnsense_http_vhost_plugins/*.conf;
#include tls.conf;
include fastcgi_params;
include fastcgi_params;
include b21a09c6-db5d-4ce0-bfe0-dd7e31d89811_pre/*.conf;
include 7b884db8-eafa-43d0-bdae-ec4a66a97cad_post/*.conf;
include b21a09c6-db5d-4ce0-bfe0-dd7e31d89811_post/*.conf;
#include tls.conf;
include fastcgi_params;
include fastcgi_params;
include 7b844599-dbd4-4b45-ad56-e22dd094d6d5_pre/*.conf;
include 016848f7-b0de-401b-b961-b7bfeed575ab_post/*.conf;
include 7b844599-dbd4-4b45-ad56-e22dd094d6d5_post/*.conf;
#include tls.conf;
include fastcgi_params;
include fastcgi_params;
include f94e4a2e-e9ea-419b-a5b8-763890eaa89b_pre/*.conf;
include d9acf7d4-f0b5-4530-b574-ad4b28375e18_post/*.conf;
include f94e4a2e-e9ea-419b-a5b8-763890eaa89b_post/*.conf;
#include tls.conf;
include fastcgi_params;
include fastcgi_params;
include f857a060-bf3e-4d6d-af2a-5073ee117b2d_pre/*.conf;
include cc8de2e8-3e31-4994-bd0c-5712a874fb04_post/*.conf;
include f857a060-bf3e-4d6d-af2a-5073ee117b2d_post/*.conf;
#include tls.conf;
include fastcgi_params;
include fastcgi_params;
include 040f7fe9-396e-4b8e-8e4c-19a3eff357c4_pre/*.conf;
include 5eeb9519-02e7-4dee-9368-f5dd50f5779d_post/*.conf;
include 040f7fe9-396e-4b8e-8e4c-19a3eff357c4_post/*.conf;
#include tls.conf;
include fastcgi_params;
include fastcgi_params;
include fcdd1729-8503-4055-80e3-cf74112ca928_pre/*.conf;
include 8498a998-7bbf-4401-80aa-7498170d3a34_post/*.conf;
include fcdd1729-8503-4055-80e3-cf74112ca928_post/*.conf;
include opnsense_stream_vhost_plugins/*.conf;
root@cerberus:~ # grep -n -A1 -B1 _post /usr/local/opnsense/service/templates/OPNsense/Nginx/location.conf
208-{% endif %}{# honeypot #}
209: include {{ location['@uuid'] }}_post/*.conf;
210-}
{% endif %}{# honeypot #}
include {{ location['@uuid'] }}_post/*.conf;
}
@klamath I'm not sure why your quoting my message, but as said if it's purely about netmap, one could try to use bridge to pinpoint issues if they exists for their setup. It's definitely not the case that there are issues in all releases, we test the hardware we provide on periodic bases and haven't seen a lot of (major) issues ourselves.
Quite some reports about performance are related to too optimistic assumptions (e.g. expecting 1Gbps IPS on an apu board for example) or drivers which aren't very well supported (we ship what's being offered upstream, if support isn't great in FreeBSD for netmap, it highly likely isn't great on our end). IPS needs quite some computing power and isn't comparable to normal routing/firewall functions at all in terms of requirements.
When it comes to testing, we tend to offer test kernels and release candidates on periodic bases. To help catching issues up front, please do test, document behaviour when experiencing issues, and try to track them to FreeBSD bug reports if they exists. When there are fixes available upstream, we often assess if we can backport them into our system. Quite some fixes have been merged in the last versions for various drivers (with quite some help from the Sensei people as Franco mentioned), I haven't seen side affects in terms of performance myself, but that doesn't mean they don't exist for some drivers.
Best regards,
Ad
I haven't seen performance issues on my setup between these versions, but since there have been quite some fixes around netmap in different kernels, it's often a good idea to check if it's Suricata causing issues or netmap.
There is a simple "bridge" tool for netmap available in the kernel source directory, if people want to check netmap behaviour on their hardware they can always build the tool and create a bridge between the card and the host-stack to rule out certain driver issues.
To install it, you need the kernel source directory in place (/sur/src), you can use the build tools (https://github.com/opnsense/tools) to checkout all sources on your machine.
When the sources are in place, you can build the tools using the following commands (on amd64):Code: [Select]cd /usr/src/tools/tools/netmap/
make bridge
Next make sure netmap isn't used (no Suricata or Sensei) and create a bridge between the physical connection and the host stack, assuming the interface in question is called vmx2, the command would look like:Code: [Select]/usr/obj/usr/src/amd64.amd64/tools/tools/netmap/bridge -i netmap:vmx2 -i netmap:vmx2
Wait a few seconds and start the test again with OPNsense in between. When netmap isn't interfering the test with or without bridge should show roughly the same numbers.
Best regards,
Ad
Any other version than 20.7.8_4 does not have the signature fingerprint for 21.1.. I'm not sure why you are not on this version.
There is the "-i" parameter to do insecure upgrades, but it's nicer to not use it and use the latest 20.7 release with:
# opnsense-update -kr 21.1
# opnsense-shell reboot
Cheers,
Franco