Recent Posts

1

19.1 Production Series / Re: SQUID + LDAP error since upgrade.

« Last post by franco on Today at 11:52:04 am »

Well, it looks like LDAP wasn't configured for Squid?

It also like the user-proxy-auth privilege is missing here for the user, which should have been there already?


Cheers,
Franco

2

German - Deutsch / Re: Firewall - state table, table entries

« Last post by JeGr on Today at 11:39:09 am »

Zu ungeduldig vermute ich. Nach einem Tag schon die Glocke rühren ist ein bisschen schlechter Stil was Foren angeht.

Ich muss gestehen, dass ich auch deine Frage nicht ganz verstehe. Das sind zwar grundverschiedene Werte und ich erkenne da gerade nicht, wo dein Verständnisproblem ist. Vielleicht kannst du es nochmal kurz klarstellen, was du zu den beiden Werten wissen willst?

3

German - Deutsch / Re: IPv6-NAT 1:1 auf IPv4

« Last post by JeGr on Today at 11:37:38 am »

> Bekommst du vom Anbieter tatsächlich nur ein /64 ? Das wär ja schon bescheiden. Ich kenne kaum nen Anbieter der nicht mindestens ein /56er vergibt, sodass du für jedes Interface theoretisch ein eigenes Netz haben kannst.

Da stimme ich zu. Wir sind selbst RIPE Mitglied und es wird für Hoster, ISPs und sonstige Dienstanbieter eigentlich klar definiert, dass dem Kunden ein entsprechendes Kontingent an Prefixen zur Verfügung stehen soll/muss. Bei ISPs ist IMHO das empfohlene Minimum ein /60 und /56 die Vorgabe, die man umsetzen soll(te). Jeder ISP den ich bislang gesehen habe, Telekom, Kabel, etc. geben per IPv6 eigentlich immer ein /56er Prefix mit raus, das _zusätzlich_ auf das Uplink /64er draufgeroutet wird.

@OP: Würde mich schon sehr wundern, wenn das in deinem Fall anders wäre

4

German - Deutsch / Re: Lokale Domain mit Unbound DNS

« Last post by JeGr on Today at 11:32:18 am »

@theq86
.home ist eine offizielle gTLD. Ist also genauso ungeschickt zu nutzen als "meinzuhause.de". Wenn man ordentlich spielen möchte UND ggf. später noch mit LetsEncrypt offizielle Zertifikate erstellen möchte, sollte man sich eine Domain kaufen/zulegen und entweder (wenn sie extern gar nicht genutzt wird) diese nutzen oder (besser) eine Subdomain davon intern nutzen. Sowas wie "home.mydomain.de".
Was vielleicht mal erlaubt war bevor .home offiziell wurde (siehe auch das Chaos um .box, .local und andere TLDs die gern fälschlich verwendet wurden) ist inzwischen klar geregelt. Der OP hat hier völlig recht, die IANA schreibt in RFC8375 die "home.arpa" als definitiv für Heimnetze verwendbare Domain aus. Damit hat sie in etwa den gleichen Status wie ".test" auf RFC2606 allerdings wird .test eher für Labs o.ä. genutzt und liest sich dann nicht so schön.

Wenn man sich an die Domain Spielregeln hält, hat man nicht hinterher Probleme mit allerlei DNS Resolvern oder Diensten, kann hinterher ordentliche Zertifikate nutzen und lernt dabei noch was über DNS.

Wer das alles nicht will oder braucht, sollte aber statt dessen zu einer eindeutig NICHT aufzulösenden TLD greifen. Es gibt dafür bspw. in RFC2606 festgeschrieben die TLD .test. Alles was bspw. <meinname.test> ist, wird von DNS Forwardern/Resolvern extern nicht weitergeleitet oder aufgelöst, da sie per RFC dazu angehalten sind, diese Requests nicht zu bearbeiten, außer sie sind selbst SOA (also für die entsprechende Domain zuständig). Andere sind .example für Dokus, .invalid die immer negativ aufgelöst sein müssen und .localhost. Diese special use TLDs sind für interne Zwecke gedacht und werden von externen DNS Servern nie/nicht aufgelöst.

TL;DR

Setzt ihr eine Spielwiese auf und offizielle Domains oder Zertifikate sind euch wurscht?
-> {irgendeinname}.test ; Bspw. mydomain.test

Ihr wollt nur euer Heimnetz ordentlich aufbauen, spätere Zugriffe oder Zertifikate sind egal?
-> {irgendeinname}.home.arpa ; Bspw. mydomain.home.arpa

Ihr wollt das in eurem Heimnetz nutzen und ggf. später per DynDNS, IP6 o.ä. von extern drauf zugreifen oder ein ordentliches internes DNS haben?
-> {subdomain}.{eure-echte-domain}.{tld} ; Bspw.: lan.mydomain.de


=> https://tools.ietf.org/html/rfc2606 (.test, .example etc.)
=> https://tools.ietf.org/html/rfc6761 (.test, .example etc.)
=> https://tools.ietf.org/html/rfc8375 (migration from .home to .home.arpa)

5

19.1 Production Series / Re: Site-to-Site IPsec AND IPsec Client behind NAT

« Last post by hbc on Today at 11:21:48 am »

Try:

Code: [Select]

interfaces_use = igb0
Without quotes. That works at least in my installation.

6

19.1 Production Series / NAT before IPSEC - Bug??

« Last post by olest on Today at 11:18:54 am »

Hi,

I have tried to setup NAT before IPSEC.

Followed this how to doc:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html

Is it not working with 19.1?

I havn't tried with 18.7.

(tested with a pfSense instead of my opnsense box and then it is working)

7

19.1 Production Series / OpenVPN client tap - routing traffic?

« Last post by Bytechanger on Today at 10:56:14 am »

Hi,

I want to connect to another network via OpenVPN TAP.

My network is 172.30.90.0/24
Other Network 192.168.1.0/24

The tunnel starts and the OpenVPN device is up with an IP Adress from 192.168.1.0/24.
Traffic should go from my network to 192.168.1.0 network (from other to mine not required).

How can I configure that all 192.168.1.0/24 traffic is routet to the other network?

Greets

Byte

8

General Discussion / OPNsense replasing sender's IP address in header

« Last post by it.dep on Today at 10:27:22 am »

Hi guys!

The scheme of the mail server:
Internet -> Gateway 192.168.2.1 -> OPNsense Haproxy 192.168.2.8 -> Exchange2019 192.168.2.5

According to this scheme, in all incoming letters to Exchange, the IP address of the sender is replaced with the IP address 192.168.2.8 (OPNsense Haproxy).

In the screenshots it is clearly visible: True IP - configuration without OPNsense, False IP - configuration with OPNsense.

True IP


False IP


We use spam filter ORF Fusion. For spam filter to work correctly, it is necessary that all incoming messages are with the sender's IP addresses, and not replaced by local IP OPNsense.

Is it possible to fix it? What can we do in this situatuation?

9

Russian - Русский / OPNsense заменяет IP адреса отправителей писем

« Last post by it.dep on Today at 10:24:29 am »

Добрый день.

Схема работы почтового сервера:
Internet -> Gateway 192.168.2.1 -> OPNsense Haproxy 192.168.2.8 -> Exchange2019 192.168.2.5

По такой схеме во всех входящих письмах на Exchange IP адрес отправителя заменяется на IP адрес 192.168.2.8 (OPNsense).
На скриншотах это наглядно видно: True IP - конфигурация без OPNsense, False IP - конфигурация с OPNsense.

True IP


False IP


Мы используем spam filter ORF Fusion. Чтобы spam filter работал правильно, необходимо чтобы все входящие письма были с реальными IP адресами отправителя, а не заменялись на локальный IP OPNsense.

Как сделать так, чтобы IP адреса отправителей не менялись на локальный IP OPNsense ?

10

General Discussion / Re: Transparent Proxy and Redirect Problem

« Last post by mimugmail on Today at 10:13:52 am »

It seems you only have transparent for HTTP and not HTTPS, while manually adding proxy would also add HTTPS. So you maybe test with HTTPS sites and it doesn't work?