Messages

How does your NAT Rule look like?
Did you create a Firewall Rule too?

Hi!

I too noticed that the aliases stopped working for me after upgrading to 18.1.4.

Alias looks like this: alias2.png
Firewallrule for testing looks like this: fwrule.png

When I change the content of the alias to the IP of my machine and restart the ping, it is being blocked -> rule working correctly.

This was working for me with 17.7. I was able to test this issue on two different machines. Are we doing something wrong?

Cheers

Hello,

I don't know since when this started but my webproxy setup somehow blocks access to the firewall webinterface:

Code Select Expand

Failed to establish a secure connection to 192.168....

The system returned:

(92) Protocol error (TLS code: X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN)
Self-signed SSL Certificate in chain: /C=CH/ST=Zuri/L=Zuri/O=Fulltier Gmbh/emailAddress=fulltier@localhost.local/CN=FulltierInternalCA

This proxy and the remote host failed to negotiate a mutually acceptable security settings for handling your request. It is possible that the remote host does not support secure connections, or the proxy is not satisfied with the host security credentials.

Your cache administrator is fulltier@localhost.local.


So yes, the certificate of the webinterface is self-signed by the internal CA of course. But this used to be no problem.
When I access the webinterface directly (without proxy) I have no issues, so I assume this has to do something with squid.

Setup:
- 18.1.3/18.1.4
- Webproxy local cache is disabled.
- Webinterface IP is in Proxy "SSL no bump sites"

Steps taken:
- Upgrade to 18.1.4
- Restart webproxy
- disable and re-enable SSL-Inspection

I even deleted the mentioned server certificate and created a new one under the same CA. Now when I try to access, I still see the old certificate which was deleted. Is this old certificate cached somewhere in squid?
Public HTTPS sites work fine.

PS: when I access with the proxy disabled, I see the new certificate...

Regards and good weekend

Hi guys,

I was playing around with HTTPS interception and noticed that the webproxy seems to accept revoked certificates (see screenshot revoked_interception.PNG).

If I disable HTTPS interception and try the testpage again, my browser blocks this page (see screenshot revoked_nointerception.PNG).

Is there something I can do to block those certificates using the webproxy? Other certificates, for example expired ones, get blocked correctly.

Cheers,
Netranger

Someone else with real knowledge of this module has to help you here. All I can say is I am not sure if a port scan should trigger an alarm anyway, at least I don't have a rule for it. But I have other rules alerting all the time, for example File Tracking GIF when surfing.

Hmm no I never played with that, always used "aho-corasick". Have you tried with this?

You could disable one after another until you find the one which is the problem.
I have 9 active ruleset with almost full bandwidth.

Cheers,

Was passiert wenn Du in Rule 10 nur Deinen Client nimmst, also ohne /24 am Ende und das Interface nochmal auf WLAN stellst? Ansonsten sehe ich auch keinen Unterschied zu meinem Setup.

Cheers,

Hi

I have the same box as you and same version of OPNSense.
I experienced similar behaviour. The following ruleset used a big chunk of my performance:
ET open/emerging-trojan

Did not test this one but i read that this is quite performance-hungry as well:
abuse.ch/Dyre SSL IPBL

If I just use a few specific ones I don't see a big performance impact.

Cheers

Huhu,

Hmm ist Deine Firewall aktuell, sprich 17.1.6?

Also habs grad nochmal eingeschaltet zum testen und bei mir läuft es mit einer Pipe und einer Rule:

Pipe:
10   Mbit/s    <Maske leer!>    PipeDown-10Mbps

Rule:
21   WLAN   ip   any   192.168...(IP vom PC)   PipeDown-10Mbps   ShapeDown_PC

Speedtest zeigt 9.6 Mbit, kommt also hin. Ursprünglich hatte ich es auch auf WAN gestellt aber das hat dann nicht funktioniert.

Cheers,
netranger

[LAN]

Wichtig ist noch, dass wenn Dein Client z.B. am Interface LAN hängt, dann musst Du logischerweise auch LAN auswählen in den Rules. Im Howto steht überall das Beispiel WAN was mich eher verwirrt hat. Ausser das Interface an welchem die Clients hängen heisst bei Dir tatsächlich WAN, dann würde es passen :o :D

hmm no 192.168.1.1 in my case is not the "local" firewall IP. It is the IP of my default gateway, the remote IP if you will. So it makes sense that this is monitored.

No idea what it was however.

Thanks for your feedback! I used the bootstrap command because I also had this issue:
https://forum.opnsense.org/index.php?topic=4916.msg20552

So now I checked the log and found something:

May 8 13:20:08   apinger: No usable targets found, exiting
May 8 13:20:08   apinger: Starting Alarm Pinger, apinger(27708)

Then I looked at the Gateway configuration. There is one entry with my router IP as "Gateway" and the same IP as "Monitor IP" which is correct... (192.168.1.1). But when I click to edit this gateway, the monitor IP field is empty, not sure if this is normal? So I typed 192.168.1.1 in the "Monitor IP" field and save and guess what - apinger starting again :D no idea why 

Cheers,

how can you start it? when I click the play button to start the service manually, nothing happens.

[Services > DHCP > Server]

Good morning guys!

I have a strange behavior after upgrading to 17.1.6:

It seems that my DHCP lease no more contains a default gateway ;D I get my internal IP address as usual but default gateway is just empty. When I set a static IP and static default gateway on my client the connection works again. So in order to fix this I went to Services > DHCP > Server and in the "Gateway" field, which was empty, I did set the firewall IP (for example 192.168.1.1). And now after ipconfig /renew on the client, everything works again. I am not sure about the config of this field before my upgrade though... if this got deleted or the mechanics changed?

Another thing I noticed after the upgrade (not sure if this has something to do with this): The apinger Gateway Monitoring Daemon fails to start, it just stays red. Is there a log for this somewhere so I could get some information?

I updated from 17.1.3 with the bootstrap command because I wanted (needed) a clean installation because I originally came from the 17.1 beta version.

Best,
Net

le process ICAP n'est pas partie de OPNSense.

Regards,