Messages

1

Web Proxy Filtering and Caching / NGINX error while reading response header from upstream

« on: March 26, 2022, 05:18:13 pm »

Hi,

After updating my OPNsense to the latest version, NGinx with the error:
 
Errors*1 upstream timed out (60: Operation timed out) while reading response header from upstream


I found this help -> https://ma.ttias.be/nginx-proxy-upstream-sent-big-header-reading-response-header-upstream/#:~:text=If%20the%20HTTP%20headers%20contain,configurations%20to%20your%20location%20block..

I changed the buffer option, but other errors occur and the service does not start.

This error in the > Services > Nginx > Logs > Global Error:
proxy_busy_buffers_size" must be smaller than the size of all "proxy_buffers" minus one buffer in /usr/local/etc/nginx/nginx.conf:656

Any configuration suggestions?

Cump.
Marchon
os-nginx 1.26
OPNsense 22.1.4_1-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1n 15 Mar 2022
Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz (2 cores, 4 threads)

2

General Discussion / Help migrating TinyDNS to Unbound DNS.

« on: October 07, 2019, 06:56:53 pm »

Hello,

I would like a tip.

I need to migrate a TinyDNS to OPNsense Unbound DNS, but currently TinyDNS has 1,600 records.

Do you know a way to do some type of export/import or will I have to do all the records manually?

Thank you.

3

General Discussion / Re: Nginx reverse proxy webdav status code 405 Method Not Allowed.

« on: October 07, 2019, 06:50:15 pm »

Thank you Fabian,

This is an application, I already requested the dev team to complete the HTTP request for testing. As soon as I receive I follow the tests and inform the result.

Thanks.

4

General Discussion / Re: Nginx reverse proxy webdav status code 405 Method Not Allowed.

« on: October 03, 2019, 10:44:20 am »

Good morning Fabian,

After I switched to OPNsense, users of a system started reporting that they are receiving the error "405 Method not allowed". I had this same problem a few years ago when I activated the pound and to solve at the time I had to set this parameter in pound xHTTP.

Pound manual.
https://linux.die.net/man/8/pound

But now I have the same problem. In the Nginx log I see the 405 log as follows attachment.

5

General Discussion / Nginx reverse proxy webdav status code 405 Method Not Allowed.

« on: October 02, 2019, 04:38:12 pm »

Hello,

I recently migrated my LINUX with POUND to OPNsense with NGINX. I now have a problem accessing webdav with status code 405 (Method Not Allowed). With POUND I decided to add the module "xHTTP 3", to allow extensions of MS WebDAV verbs (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).

How to modify it in Nginx in OPNsense?

6

General Discussion / Re: Newbie Question: Changing NAT Rules via SSH

« on: June 28, 2019, 11:11:42 am »

Hallo DanielE,

If I understood correctly, the connections occur by name and when the main equipment fails the script changes the A record in its DNS to the IP of the second device (failover) ?!

If yes, and if your OPNsense firewall uses the same DNS for queries, create a host alias with the name and apply that alias to the target of your portforward rule.

7

General Discussion / Re: How to routing to another gateway

« on: June 28, 2019, 10:48:37 am »

Hello,

See https://docs.opnsense.org/manual/multiwan.html

8

General Discussion / Re: 2 DHCP servers and 2 OPN servers: broadcast query

« on: June 27, 2019, 01:49:16 pm »

Hello,

By default DHCP requests are sent to a braodcast address and routers do not forward broadcast. It is likely that your machines are in the same braodcast domain.

I recommend the following test:

1 - Run a sniffer on the two firewall (tcpdump -n -i on 0 port 67 and port 68)

2 - Choose a client machine that occurs the problem and take note of the mac address.

2 - On this client machine run ipconfig / renew.

3 - Check the two firewall for the requests of this machine.

Repeat ipconfig / renew a few times, if the requests reach the two firewalls confirm that your machines are in the same braodcast domain.

9

General Discussion / Re: Problem Nginx reverse proxy

« on: June 27, 2019, 11:17:17 am »

Hello,

Thank you for your help!

Going back to this problem, I created a workaround with Nat PortForward while I do not discover the cause of the problem. I will analyze together with dev team and any novice I post here.

10

General Discussion / Re: Problem Nginx reverse proxy

« on: June 13, 2019, 10:56:16 am »

You can try it locally using curl.

Yes, using the curl I get access to the webservice successfully.

problem with the firewall (NAT or Filter).

I deactivated all Ports Forward, I do not have One-to-One and nats Outbounds have only one of my LAN for the Internet and rules have also been deactivated with "pfctl -F rules".

Are you using HTTPS?

Yes, all in HTTPS on port 443 and with the same certificate.

Is only IIS broken?

Excuse me! I did not understand that question.
All 4 webservices are on the same IIS server and only this webservice has this problem.

Maybe an information I have not given before, with this problem I had to create a contouring solution that was to create a PortForward that works normally.

Another detail is that my WAN interface is not directly connected to the Internet with a public IP, rather it has an ISP router that forwards to my WAN that has 192.168.x.y private addresses.

11

General Discussion / Problem Nginx reverse proxy

« on: June 12, 2019, 05:06:27 pm »

Hello,

I have an OPNsense 18.7.10 running with Nginx 1.5 as a reverse proxy for 4 webservices that are on an internal server.

Internet -----> Nginx/OPNsense -----> IIS6.0

I do not know where I'm wrong that only a webservice is experiencing a problem. All items such as Upstream, Upstream Serve, Location, and HTTP Server have been configured in the same way with the same options. In short, I put the first one to work and the others are clones and only changed the addresses.

These webservices were running correctly on another Nginx Linux (CentOS 5.9).
All use the same certificate.

When I test the webservice through the browser the webservice page is displayed successfully and I see the packets entering my WAN interface and exiting the LAN interface towards the IIS server and I also see access logs in the successful Nginx.

But when access is done by the application, I only see the packets arrive on my WAN interface, I do not see them coming out through the LAN interface towards the IIS server and I also do not see any logs in Nginx, neither access log nor error log.

I already checked and also does not have a firewall block, I even did a test with "pfctl -F rules" and even then the behavior is the same.

Can anyone help me?

12

General Discussion / Re: Captive Portal problem 802.1q

« on: March 20, 2019, 12:55:52 pm »

Nginx's workaround worked perfectly, thanks for the tip!

I think the problem with captive portal is the fact, that more and more websites migrate to https, but I think the portal page is only triggered by a request on http.

In my case, the problem only occurs when Captive Portal over HTTP on an 802.1q tagg interface. In this scenario, the page to authenticate only loads if I enter the URL manually http: // ip_fw: 8000. However, if my firewall is working with HTTPS the page to authenticate is automatically loaded.

Did you try to open a plain http page?

Yes, the behavior is the same.

13

General Discussion / Captive Portal problem 802.1q

« on: March 19, 2019, 12:32:25 pm »

Hello,

I need help, I believe this is a bug!

I have a scenario where I use wpad for my LAN and I have a GUEST for my clients and I need Captive Portal to register these users.

My firewall

WAN (em0) - 200.199.199.100
LAN (em1) - 192.168.0.1/24
GUEST (vlan100_em1) - 192.168.100.1/24

It happens that when I have the Web GUI in HTTP to provide the wpad to LAN clients the Captive Portal page does not automatically load in the 802.1q tagg interface. If I use the same configuration on the LAN page loads automatically and enables authentication, when the clients of the 802.1q tagg interface the page does not load automatically, it is necessary to enter the URL address to be able to authenticate.

If I change my Web GUI settings to HTTPS Captive Portal works fine for all interfaces, but LAN clients can not get the wpad information because of the certificate error that is not valid.

I thought that disabling the "Disable web GUI redirect rule" redirection in System> Settings> Administration would solve my problem, but not. When HTTP redirection is disabled, HTTP is disabled.

Anyone have any ideas for workaround?

14

General Discussion / Blacklist and Remote ACL not working

« on: March 13, 2019, 07:25:11 pm »

Hello,

I have an Opensense 19.1.1 with Basic Proxy and no authentication.

I tried to block facebook through the conventional GUI blackslists in "Services > Web Proxy > Administration > Access Control List" but even added .facebook.com, ".facebook.com", facebook.com and "facebook.com" access is still allowed by the proxy. My ACL whitelist is empty.

Looking at the cli/bash configuration file "/usr/local/etc/squid/squid.conf" was as below;
# ACL - Blacklist - User defined (blackList)
acl blackList url_regex \.facebook\.com
acl blackList url_regex  "\.facebook\.com"
acl blackList url_regex facebook\.com
acl blackList url_regex "facebook\.com"

and I see in the logs the access being allowed
192.168.10.254 TCP_TUNNEL/200 370105 CONNECT www.facebook.com:443 - HIER_DIRECT/185.60.219.35 -

So I also added Remote ACL UT1 and selected only porn and social_network and I still see the access being allowed by the Proxy.

Log access
1552499817.222 28   192.168.10.254 TCP_TUNNEL/200 39 CONNECT staticxx.facebook.com:443 - HIER_DIRECT/185.60.219.16 -
1552499817.222 32   192.168.10.254 TCP_TUNNEL/200 39 CONNECT staticxx.facebook.com:443 - HIER_DIRECT/185.60.219.16 -
1552498763.181 270673   192.168.10.254 TCP_TUNNEL/200 249290 CONNECT www.facebook.com:443 - HIER_DIRECT/185.60.219.35 -
1552498744.174 248720   192.168.10.254 TCP_TUNNEL/200 1740 CONNECT facebook.com:443 - HIER_DIRECT/185.60.219.35 -

I checked the /usr/local/etc/squid/acl/UT1 file and it contains 1,968,784 lines and with facebook 494 and even then access is allowed.

# wc -l /usr/local/etc/squid/acl/UT1
1968784 /usr/local/etc/squid/acl/UT1

# grep facebook /usr/local/etc/squid/acl/UT1 | wc -l
494

Is there something I'm doing wrong?

Thanks

15

General Discussion / Re: how to get a crash report?

« on: February 27, 2019, 04:41:38 pm »

 
Thanks