Menu

Show posts

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.

Show posts Menu

Messages - netranger

#1
thank you for the screenshots!
according to https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus I would need to put some wildcard entries  :-\ for you it worked without that?
#2
Ok that would at least be a work around. Could you provide a screenshot of how you did it?

BR,
NR
#3
Hi,

Goal
Get Windows Updates working over transparent HTTPS Squid Proxy.

Problem
Some entries in the "SSL no bump sites" list seem to be inactive.

Version
19.7.4_1

Description
For example, one of the sites used for windows updates seems to be settings-win.data.microsoft.com. No matter what I tried, I could not get this site to not be intercepted. The reason I know it is not intercepted is because I can see the full path in the logs. I tried the following no-bump configurations:

.microsoft.com -> Log shows https://settings-win.data.microsoft.com/settings/v2.0/WSD/WaaSAssessment? is being accessed.

settings-win.data.microsoft.com -> Log shows https://settings-win.data.microsoft.com/settings/v2.0/FlightSettings/FSService? is being accessed.

.data.microsoft.com -> Log shows https://settings-win.data.microsoft.com/settings/v2.0/wsd/muse? is being accessed.


So does it work at all? Yes it does. For example with a bank site:

.db.com -> Log shows 160.83.8.143:443 is being accessed. No path visible which means no-bump entry works.
Removed the .db.com entry again -> Log shows https://www.db.com/company/img/favicon.ico is being accessed.

In between I checked the content of the config file, looked good to me:

# less /usr/local/etc/squid/nobumpsites.acl
.data.microsoft.com
.db.com


Any hints will be greatly appreciated.

BR,
NR
#4
Hi,

yes, transparent means the client doesn't see any configuration for this. In order to do this you would need:
1. a NAT rule which redirects your web traffic to your proxy (for example redirect port 80 to 3128)
2. a firewall rule which allows your client to connect to your transparent port (for example 3128)

Please post your rule setup.

Edit: also check this https://docs.opnsense.org/manual/how-tos/proxytransparent.html

BR,
NR
#5
Thank you for the info and the awesome work! Upgrade went well :D

Cheers,
NR
#6
Hi there,

has the upgrade path already been changed or is there another way to directly go to the latest release?

Cheers,
NR
#7
Quote from: franco on April 30, 2019, 07:42:59 AM
If you raise a ticket I can take a closer look.

https://github.com/opnsense/core/issues/new/choose


Ticket created! https://github.com/opnsense/core/issues/3454

I'll be happy to provide more configs or log files if you need them. Thanks a lot for looking into this.

Cheers,
NR
#8
Quote from: franco on March 22, 2019, 07:59:24 AM
Works for me: logs are redirected to Services: Captive Portal: Log File. I'm not sure why but that's what it is.

And you can forward "Portal Auth events" remotely then (System: Settings: Logging).


Cheers,
Franco

Hi guys,
sorry I'm probably misunderstanding something obvious here. But does this mean in order to get the squid logs into my syslog server I need to activate the Captive Portal (which I'm not using)?
I can see the squid logs in the captive portal page and "Portal Auth events" forwarding is activated, but I don't get those logs at my syslog server.

Thank you and good start into the week,
NR
#9
Did you find out how?
I am in the exact same situation. External logging works, but no Webproxy logs.
#10
Hi

Maybe also try to click on Download ACLs, then wait until the traffic vanishes and only then click apply. If downloaded correctly, you should be able to see the list in:
/usr/local/etc/squid/acl

Regards
#11
openssl s_client -connect routerIP:443

output:
....
Verify return code: 18 (self signed certificate)
....


According to this source I tried the following: https://www.madboa.com/geek/openssl/#verify-system

mkdir /etc/ssl/certs
cd /usr/local/share/certs/
openssl s_client -showcerts -connect routerIP:443 < /dev/null | openssl x509 -outform PEM > router.pem
openssl x509 -noout -hash -in router.pem


output:
12345678 (8-digit hash of the cert)

ln -s /usr/local/share/certs/router.pem /etc/ssl/certs/12345678.0
openssl s_client -connect routerIP:443


output:
...
Verify return code: 0 (ok)
...


So my understanding is that now openssl trusts my router-certificate but when I try via proxy, I still cannot connect and get the same original error in the browser. Any hints? ::)
#12
you mean "local" to the client? yes that's already the case, public HTTPS sites are intercepted just fine.

I only have this problem with admin-webpages in the LAN (also for the router interface as I just found out).
#13
I just checked shallalist and it updated correctly for me a few days ago.

If I remember correctly one had to apply the list first once, in order for the categories to become available. Have you tried to apply the list once without any categories?

Cheers
#14
Okay so this means I can either place a valid server certificate for all admin-webinterfaces in my LAN (which I don't really want as there are quite a few) or I can make squid trust these certificates. How can I do the latter?
#15
Could you please move my thread to the "Web Proxy Filtering" chapter if it is placed wrong here.

Shouldn't an entry in the "SSL no bump site" be enough in order to not get any warnings about self-signed certificates? :o