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 - stefan21

#31
Quote from: stefan21 on July 09, 2022, 10:15:18 AM
The sense ist sitting behind a Vodafone cable modem. Configured as exposed host. The cable modem should still run in bridged mode. There have been updates from vodafone, therefore I'm not quite sure if there's something messed up in the config. I'll check this on monday.

On monday morning the interface with the intel nic didn't work any longer. I removed the nic and put a realtek in the machine. Interestingly no error shows up in any log which may lead to a defunct nic.

The last vodafone update messed up my configuration. It's a Fritz!Box 6591 Cable BH. Exposed host was disabled, realtime prio was disabled and also self port opening. I changed the settings back.

I'll report if the errors are gone.

regards,
stefan

#32
Running on hardware:

# sysctl -a | grep -E 'dev.(igb|ix|em|bg).*.%desc:'
dev.em.0.%desc: Intel(R) Legacy PRO/1000 MT 82540EM
dev.bge.0.%desc: Broadcom NetLink Gigabit Ethernet Controller, ASIC rev. 0x5784100

Had to revert back to

OPNsense 21.7.8-amd64
FreeBSD 12.1-RELEASE-p22-HBSD
OpenSSL 1.1.1m 14 Dec 2021

Changed the intel nic to LAN (before it was on the WAN)
Seems to run stable as before.

In the 21.7.8 system log:

kernel   em0: link state changed to DOWN
opnsense[81347]   /usr/local/etc/rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.x.x.x ::)
kernel      em0: link state changed to UP
opnsense[34693]   /usr/local/etc/rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.x.x.x ::)
opnsense[50625]   /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'em0'
opnsense[50625]   /usr/local/etc/rc.newwanip: On (IP address: 192.x.x.x) (interface: LAN[lan]) (real interface: em0).

The sense ist sitting behind a Vodafone cable modem. Configured as exposed host. The cable modem should still run in bridged mode. There have been updates from vodafone, therefore I'm not quite sure if there's something messed up in the config. I'll check this on monday.

I'm running another sense (also Hardware) with the latest version. No intel nics, mainly the same configuration. No problem with this machine. Does not loose WAN nor wireguard.

regrads,
stefan

Edit: both machines are configured with IDS and IPS on WAN and ZENARMOR on LAN
Edit: NO mac spoofing
#33
General Discussion / Re: DNS Hairpin Rule for Pi-Hole
January 24, 2022, 02:42:06 PM
Hmm, something's not quite correct. From the pi-hole log (which is spilling rapidly):

dnsmasq[2705]: query[NS] . from 192.168.52.1
Jan 24 14:35:03 dnsmasq[2705]: forwarded . to 127.0.0.1
Jan 24 14:35:03 dnsmasq[2705]: reply error is REFUSED

and

Jan 24 14:32:36 dnsmasq[2705]: query[A] 2.0.de.pool.ntp.org from 192.168.52.1
Jan 24 14:32:36 dnsmasq[2705]: forwarded 2.0.de.pool.ntp.org to 127.0.0.1
Jan 24 14:32:36 dnsmasq[2705]: reply error is REFUSED

The OPNSense is configured for using chrony - the query to de.pool.ntp.org must come from some client. Unbound in OPNSense is turned off. All DNS are pointing to the pi-hole.

However the pi-hole is blocking requests and filtering is up.

Any thoughts?
#34
General Discussion / Re: DNS Hairpin Rule for Pi-Hole
January 24, 2022, 07:11:32 AM
@Greelan

Thank you for your feedback and time in this. I'll try it out and let you know.

regards,
stefan
#35
General Discussion / Re: DNS Hairpin Rule for Pi-Hole
January 24, 2022, 12:10:20 AM
Quote from: Greelan on August 20, 2021, 01:55:22 PM
OK, so here is my config.

Background:

- I have a LAN interface and several VLANs on OPNsense
- I have an interface group called ALL_LOCAL which groups the LAN and those VLANs together
- My Pi-hole is on a separate box that also runs unbound as a recursive resolver. It is on the LAN
- Pi-hole listens on 192.168.1.10 and fdfd:2553:8868:1:63df:78ab:5e7e:68ee
- The Pi-hole IPs are handed out as DNS servers by DHCP and RA
- The idea is that all DNS for my network is handled by Pi-hole and unbound

Aliases:

Good evening,

and thank you for sharing your approach.

I do have a slightly different network config. The OPNSense does not act as a DHCP, this job is doing a NethServer. I'd like to implement the pihole in the LAN. Therefore I have a few questions:

a) would your setup work also in my scenario (pointing the DNS from the NethServer to the IP of the pihole)?

b) in OPNSense System: Settings: General: do I have to enter the IP of the pihole?

c) I assume in OPNSense Services: Unbound DNS: General: this one should be disabled?

Thank's for any hints.

regards,
stefan

#36
Guten Abend,

ich bin mir nicht ganz sicher, ob meine Frage zu diesem Thread gehört, falls nein, sorry.

Auf einer Opnsense 17.1.10 habe ich eine funktionierende IPSec Roadwarrior Verbindung eingerichtet. Das Mobiltelefon hat ein Zertifikat und authentifiziert sich mit einem Benutzer, dem an den Benutzer gebundenen Zertifikat und dem IPSec-Passwort. Im IPSec-Tunnel ist das Zertifikat entsprechend hinterlegt. Also Nutzer, Telefon und Tunnel haben dasselbe Zertifikat.

Wenn ich nun ein zweites Mobiltelefon genau auf dieselbe Weise einrichte und verbinde, dann wird die Verbindung auch aufgebaut.

Nun zu meiner Frage: beide Mobiltelefone erhalten dieselbe IP durch das VPN. Es wird im VPN: IPsec: Lease Status nur eine Verbindung angezeigt: Pool: 10.0.0.0/24 Usage: 1/254 Online: 1, obwohl beide Mobiltelefone verbunden sind.

Wenn ich der zweiten Verbindung einen anderen Nutzer mit einem anderen Passwort zuordne, das Zertifikat jedoch beibehalte, dann kommt keine Verbindung zu Stande. In den Logs wird ein XAUTH-Fehler ausgewiesen.

Was mache ich falsch bzw. was ist zu tun, wenn ich mehrere Mobiltelefone als Roadwarriors mit der Opnsense verbinden will? Ist es einfacher bzw. funktioniert dieses Szenario besser ohne Zertifikat(e)?

Vielen Dank für jede Hilfe.

lg, stefan

***

Gelöst:

Das eine Telefon ist ein neuer Android (BB Key2) und das andere ein (alter) BB 10. Der Blackberry Passport will eine Gruppe mit einem Passwort bei der Auswahl Xauth PSK. Ich habe keinen Weg gefunden, die Authentifizierung gegen die Opnsense zu definieren.

Wählt man hingegen bei beiden Telefonen Xauth PKI und gibt die entsprechenden Nutzer mit Passwörtern ein, dann funktioniert alles wie es soll. Das hierfür erstellte Zertifikat ist bei beiden Telefonen dasselbe.

Nicht ganz einfach bei der Vielzahl von Telefonen, die auf dem Markt sind...
#37
Version 18.1.6 installiert und ein Backup zu dieser Version eingespielt. Leider keine andere Lösung gefunden.

stefan
#38
OPNsense 18.1.10-amd64
FreeBSD11.1-Release-p11
OpenSSL 1.0.2o 27 Mar 2018

Nach einem Update auf 18.1.11 startet squid nicht mehr. Eine Version zurück auf 18.1.10 und squid 3.5.27_3 bringt leider keinen Erfolg. Alle anderen Updates von 18.1.10 auf 18.1.11 habe ich belassen.

Im Log des WebProxy steht u.a.:

Pagefaults with physical i/o:0
Fatal: Unable to open HTTP Socket

Vor dem Update lief alles problemlos.

Für eine schnelle Hilfe wäre ich dankbar. Im Zweifel würde ich gerne komplett alle Pakete auf 18.1.10 downgraden. Leider kenne ich nicht den Befehl dazu.

Grüsse,
Stefan
#39
Disabling shallalist and re-starting the web proxy solved the issue. This means, that even whitelisting a domain is being overwritten from remote blacklist. Quite easy if you know about this. Sorry for the noise.

Anyway - this leaves the question how to whitelist a domain which is in a remote blacklist?

regards,
stefan

EDIT: while playing a little around, I first deleted and then re-added the my-hammer.de domain in my whitelist. Did a "apply" with every step and restarted the proxy twice. Then I enabled in remote ACL the shallalist again. After another restart of the proxy the whitelisted domain was accessable. Very tricky...
#40
18.1 Legacy Series / Re: Web proxy whitelist issue
June 25, 2018, 06:37:21 PM
The following error was encountered while trying to retrieve the URL: http://www.my-hammer.de/

    Access Denied.

Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect.

I just don't get it - IMVHO there's nothing defined in the ACL which could prevent loading this page? The only entry in the blacklist is "imrworldwide.com".

BTW - could someone move this to the correct subforum? Sorry for posting too fast...
#41
18.1 Legacy Series / Re: Web proxy whitelist issue
June 25, 2018, 04:09:18 PM
Even if whitelisting (unrestricted access) the IP of the workstation does not help. How can that be?

Any help would be appreciated.
#42
Hello,

OPNsense is running as OPNsense 18.1.9-amd64, FreeBSD 11.1-RELEASE-p10, OpenSSL 1.0.2o 27 Mar 2018.

Services: Web Proxy: Administration Whitelist: besides some other domains: "my-hammer.de", which was the last I added.

From the log:
1529845065.736 0    xxx TCP_DENIED/403 4095 GET http://www.my-hammer.de/favicon.ico - HIER_NONE/- text/html
1529845065.715 0    xxx TCP_DENIED/403 4021 GET http://www.my-hammer.de/favicon.ico - HIER_NONE/- text/html
1529845065.681 0    xxx TCP_DENIED/403 4141 GET http://localhost:3128/squid-internal-static/icons/SN.png - HIER_NONE/- text/html
1529845065.647 0    xxx TCP_DENIED/403 4100 GET http://www.my-hammer.de/ - HIER_NONE/- text/html

The client is not able to access the domain. The previous whitelisted domains are accessable.

Anybody with an idea?

regards,
stefan
#43
Is there a solution yet?

regards,
stefan
#44
Quote from: the-mk on June 09, 2018, 10:36:14 AM
Ich würde mal schauen, welche IP-Adresse auf dem Surfstick ankommt.
Oft ist es so (zumindest in Österreich), dass bei mobilen Internet man eine private IP-Adresse zugewiesen bekommt - CGN - Carrier Grade NAT - IPv4-Adressen sind ja eher "Mangelware"...

Die angegene IP des Surfsticks ist 109.42.0.164. Um genau zu sein ip-109-42-0-164.web.vodafone.de. Ein Portscan mit nmap bringt :

Host is up.
All 1000 scanned ports on ip-109-42-0-164.web.vodafone.de (109.42.0.164) are filtered

--> also keine offene Ports.

Der Rückschluss liegt also nahe, dass entweder ein Masquarading oder NAT hinter der "öffentlichen" IP steckt.

Ergo: mit diesem Surfstick ist es nicht möglich ein VPN aufzubauen.
#45
bartjsmit,

thank you very much for trying to help.

Meanwhile I figured out, that the problem is caused by a NAT-rule. Right now I am able to connect a road-warrior to the server. I'd like to check this from a different location which I can do on monday or tuesday. If that works also, I'll be back and report.

regards,
stefan