Messages

Ok so now you have the one frontend and the two backends but no rules or conditions?
Set the rule on the frontend not the backend.
The synology doesn't have a port?

Can you please post an updated version of your config?

Is it still the same addresses you're trying to hit as the original config?

Ok so haproxy is listening on port 80 and you're saying it's not handling general http traffic hitting the FW? It won't be doing https traffic unless you have a Front end for 443.

Don't forward at all... Terminate incoming traffic on the firewall... HAProxy will then pick it up and do what it needs.
If you port forward you'll bypass HAProxy entirely.

So basically... If you match the first condition then go to the VirtualRadar... Any other traffic go to the webserver?

You only need one condition and then have the default pool as Web_Traffic... You seem to be over complicating it.

Ok... First things first...

How the config is set up currently the second front end will never be hit... You have two front ends on the same port doing the exact same thing.. Ideally only have one front end per service so one for http and one for https...

Secondly I don't see in that config any ACLs for the front end or backend.

The back ends look ok just change the frontends and add ACLs to direct to each server.

Could you please post the whole config so we can get a better idea of the whole set up?

Due to an upgrade issue we haven't been able to narrow down we will not release 20.1.8, so there will be no tag for it.

https://twitter.com/opnsense/status/1276124128509153287

We appreciate the concern and nudging, but asking for something that isn't ready will not help. What helps is inspecting process that the project has established many years ago and going from there.

2020 is an interesting year for all of us and I am personally sorry for any inconvenience caused.

Well.. Better off holding off the release until it's fixed :)

Thanks for keeping us up to date with what's going on... Thankfully I haven't found any real issues with 20.1.7 so it's not that critical waiting for the 20.1.8 update but I'm a tad crazy in the sense that I really like keeping things up to date.

2020 has indeed been crazy and we're only half way through.

So... Two key things that I would do differently. 1. have a separate front end for HTTP and HTTPS. 2. Have both the HTTP and HTTPS frontends redirect to the relevant server as you have configured with the ACL's. That would be my way of solving your problem.

As you can see with the logs, it's hitting the first front end, failing the ACL check and using the default backend anyway.

With the above... You first hit the relevant front end for that port then you determine where you want traffic to head to after that point.

I posted the same thing a couple of days ago and got this response from hbc..

Nothing to be worried about. Everybody has this button for security audit - even developers. The know about it.

@franco: feature request: add hint not to post security audits to forum and explain its use case

In that case, it might be worth applying the fix also mentioned in that thread.
Down the bottom there's a fix that should apply for 20.1.7

So.. This looks to be a fairly similar issue to this one https://github.com/opnsense/core/issues/2841.

Could you try this as mentioned by AdShellevis:
"Can anyone with the issue try to disable "Automatic outbound NAT for Reflection" in Firewall->Advanced and test again? As far as I can see that's these are the only areas in the code generating a rule with as target an interface."

Hey guys,

Not sure if you are aware or not, there are 5 packages in 20.1.7 with current vulnerabilities.

How far away are we looking for 20.1.8?

Code Select Expand

***GOT REQUEST TO AUDIT SECURITY***
vulnxml file up-to-date
clamav-0.102.2,1 is vulnerable:
clamav -- multiple vulnerabilities
CVE: CVE-2020-3341
CVE: CVE-2020-3327
WWW: https://vuxml.FreeBSD.org/freebsd/91ce95d5-cd15-4105-b942-af5ccc7144c1.html

libnghttp2-1.40.0 is vulnerable:
nghttp2 -- DoS vulnerability
CVE: CVE-2020-11080
WWW: https://vuxml.FreeBSD.org/freebsd/4bb56d2f-a5b0-11ea-a860-08002728f74c.html

unbound-1.10.0 is vulnerable:
unbound -- mutliple vulnerabilities
CVE: CVE-2020-12663
CVE: CVE-2020-12662
WWW: https://vuxml.FreeBSD.org/freebsd/a2cb7c31-9c79-11ea-a9c2-d05099c0ae8c.html

json-c-0.13.1_1 is vulnerable:
json-c -- integer overflow and out-of-bounds write via a large JSON file
CVE: CVE-2020-12762
WWW: https://vuxml.FreeBSD.org/freebsd/abc3ef37-95d4-11ea-9004-25fadb81abf4.html

gnutls-3.6.13_1 is vulnerable:
GnuTLS -- flaw in TLS session ticket key construction
CVE: CVE-2020-13777
WWW: https://vuxml.FreeBSD.org/freebsd/ef5b4f5f-a658-11ea-80d7-001cc0382b2f.html

What webserver are you using? Is it showing any errors when you attempt to access the websites? That or Traefik

Change both the front end and backend to just TCP mode.

Also you'll definitely want to set up ACLs for SSL SNI if you plan on having multiple servers.

As per this guide https://www.haproxy.com/documentation/haproxy/deployment-guides/tls-infrastructure/#ssl-tls-pass-through