Messages

Ich habe aktuell das Problem dass die Clients gar nicht über die ULA raus gehen möchten, wahrscheinlich weil die GUA noch da ist?

Ich glaube das Hauptproblem sind unterschiedliche Konfigurationen.
tiermutter kannst du bitte noch Screenshots von deinen Gateway Einstellungen und ggf. Firewall Rules posten?
Versuche auch vergeblich nen IPv6 Failover auf mein Starlink hin zu bekommen und vermute dass irgendwas fehlt.

Hey, is it a Bug or a Feature, when i configure the new Instances Client to likely the same (persist-remote-ip, remote-random, route-noexec, route-nopull, some other Parameters are missing)
as the legacy, it doesnt set a IPv4 Gateway IP on the assigned OpenVPN Client Interface.
The legacy Client does.
Is there a way to enable this? Because the OpenVPN Server has changing Gateway IPs.

Hello, i've got a problem,
my sense is connecting to a openvpn server and i want to route one special client over this connection.
This works fine but only if i enable outbound nat on the sense.
If i disable outbound nat, the client cant access internet through vpn and cant ping the server.

VPN: 10.250.0.1
Sense: 10.250.0.2
Client: 192.168.191.10
Pings:
VPN -> Sense = OK
Sense -> VPN = OK
Client -> Sense = OK
Sense -> Client = NOK
Client -> VPN = NOK
VPN -> Client = NOK

server.conf

Code Select Expand

port 54058
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.250.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
route 192.168.191.0 255.255.255.0
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_2jEVQSBICbe6x00i.crt
key server_2jEVQSBICbe6x00i.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3

ip routes vpn server

Code Select Expand

root@1becf65a:~# ip route get 10.250.0.2
10.250.0.2 dev tun0 src 10.250.0.1 uid 0
    cache

root@1becf65a:~# ip route get 192.168.191.1
192.168.191.1 via 10.250.0.2 dev tun0 src 10.250.0.1 uid 0
    cache

iptables server

Code Select Expand

iptables -A FORWARD -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

routes sense

Code Select Expand

10.250.0.0/24      10.250.0.1         UGS      ovpnc6
10.250.0.1         link#39            UH       ovpnc6
10.250.0.2         link#39            UHS         lo0

tcpdump on sense with ping from client to vpn server running

Code Select Expand

root@F1R3W4LL:~ # tcpdump -nn -i ovpnc6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc6, link-type NULL (BSD loopback), capture size 262144 bytes
01:55:31.543568 IP 192.168.191.10 > 10.250.0.1: ICMP echo request, id 31, seq 5, length 64
01:55:32.567544 IP 192.168.191.10 > 10.250.0.1: ICMP echo request, id 31, seq 6, length 64
01:55:33.591488 IP 192.168.191.10 > 10.250.0.1: ICMP echo request, id 31, seq 7, length 64
01:55:34.615450 IP 192.168.191.10 > 10.250.0.1: ICMP echo request, id 31, seq 8, length 64
01:55:35.639393 IP 192.168.191.10 > 10.250.0.1: ICMP echo request, id 31, seq 9, length 64

on the other side i get nothing

Code Select Expand

root@1becf65a:~# tcpdump -nn -i tun0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes

Looks like the packets are stuck inside the vpn or being filtered.
Has anyone an idea whats going on?
As i said, with enabled outbound nat, everything is working fine.

*on 22.1

On 22.1 what happens? Is there a solution to our problem?
Can you describe what has been changed and how to use it?

I need to keep this enabled because of VoIP.
The connections need to be killed on new IP but only on PPPoE not on VPN.

Hey, i'm facing the same issue described here
https://forum.opnsense.org/index.php?topic=14946.0
is there a way to fix this?

thanks!

Hello guys,
here a tutorial from me in English to get the domain search list under Android running.
As you may know, Android will not process or accept a from the dhcp server published domain search list.
The problem and the fix is described here:
https://www.manualslib.com/manual/1761369/Sennheiser-Mobileconnect.html?page=30

To get this running here the simple steps:
On the OPNsense WebIF select your desired network under Services -> DHCPv4
Domain name: PrimaryDomain <- note your domain
Domain search list: <your noted domain followed by the domains you want in search list, separated by semicolon>
Last item Additional Options -> click Advanced
Number: 15
Type: Text
Value: <your noted domain followed by the domains you want in search list, separated by spaces>
Click Save
Reconnect your Client and enjoy :D

Thanks to "micneu" for the "Additional Options hint"!

Danke an "micneu" für den "Additional Options" Hinweis!

Hier die kurze Anleitung:
Auf dem OPNsense WebIF das entsprechende Netzwerk unter Services -> DHCPv4 auswählen
Domain name: PrimäreDomain <- Domain notieren
Domain search list: <deine notierte Domain gefolgt von denen die in der search list sein sollen, getrennt durch Semicolon>
Letzte Zeile Additional Options -> Advanced
Number: 15
Type: Text
Value: <deine notierte Domain gefolgt von denen die in der search list sein sollen, getrennt durch Leerzeichen>
Save
Die entsprechenden Clients reconnecten und freuen :D

Guten Tag,
Android kann wohl schon immer die DHCP Option 119 (Domain search list) nicht verstehen,
was darin resultiert, dass Android die zusätzlichen Domains nicht auflöst.
Ärgerlich!
Ich habe nun diese Seite gefunden:
https://www.manualslib.com/manual/1761369/Sennheiser-Mobileconnect.html?page=30
Wo steht, dass Android wohl zusätzliche Domains annimmt indem man sie über Option 15 mitgibt.

Nun meine Frage:
Gibt es eine Möglichkeit die Option 15 (Domain name) des DHCP Servers der sense manuell einzustellen?
Über das Webinterface bekomme ich den Fehler "A valid domain name must be specified for the DNS domain."

Wäre echt super!
Vielen Dank, MfG

Hey, hat hier noch jemand seit ein paar Wochen Probleme mit 1und1?
An den Settings wurde nichts geändert, trotzdem gehen einige Anrufe (vor allem vom Festnetz aus) nicht rein.

Edit:
So, Problem gefunden.
Für alle die Probleme mit nicht eingehenden Anrufen haben:
Entweder hat es 1und1 geändert oder ein Fritzbox Update, und zwar...
1und1 nutzt (jetzt?) wohl 2 unterschiedliche SIP Server unter sip.1und1.de,
212.227.124.129 und 212.227.124.130.
Das Problem besteht darin, dass die Fritzbox nur zu einem der beiden eine Verbindung aufbaut und somit auch nur ein State für die Rückverbindung besteht.
Wenn jetzt die Fritzbox mit 212.227.124.129 verbunden ist, aber der Anruf von 212.227.124.130 rein kommt,
verwirft die Firewall der OPNsense logischerweise den INVITE, da ja kein State offen ist.
Meine Lösung: NAT Portforwarding
Interface: WAN
Protocol: UDP
Source: die beiden SIP Server IP's
Source port range: from SIP to SIP
Destination: WAN address
Destination port range: from any to any
Redirect target IP: IP Fritzbox
Redirect target port: SIP

Falls jemand eine elegantere Lösung hat, lasst es mich wissen.

Hello guys,
I'm facing an issue that I can't seem to solve correctly and I'd love to get a tip of best practices:

I've 2 wans, one of them is a PPPoe and has it's target gateway changing from time to times. As I've a SIP PBX in the background, I've set the "Dynamic state reset" flat on the advance param. Unfortunatelly, this flag does not seem to be compatiple with the OpenVPN client that I use, as once the VPN client receives via DHCP an new ip, the states are reset and the connection is dropped.

Can I somehow enable the "Dynamic state reset" flag only for one interface? Or is there anoter way to achieve this ?
Thanks a lot in advance and best regards,

Dear Wired Life,

I have been looking also and stumbled across this, https://teklager.se/en/products/router-components/wle900vx-wireless-wifi-kit .

It has the card, the cables and the antennas.

I don't know if it works but after I finish learning about everything else it is my intention to order a kit to see how it works.

Regards

I think this wont work because it has a chipset which supports 802.11ac, these are not supported by freebsd.
For me its useless because i can only fit a half size card, and this is a full size.
For you i can say a WLE200NX works perfectly in a APU.
I have WLE200NX in my APU2C4 and it works, but this card wont fit in my new build OPNsense hardware.

Hello,
i'm searching for a half size mini pcie wifi adapter which works with OPNsense.
Currently i'm having a card which does not work.

ath0: <Atheros 9285> mem 0xfea00000-0xfea0ffff irq 28 at device 0.0 on pci2
[ath] AR9285 Main LNA config: LNA1
[ath] AR9285 Alt LNA config: LNA2
[ath] LNA diversity disabled, Diversity disabled
ath0: [HT] enabling HT modes
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: AR9285 mac 192.2 RF5133 phy 14.0
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0
wlan0: changing name to 'ath0_wlan1'
ath0_wlan1: ieee80211_new_state_locked: pending RUN -> SCAN transition lost
ath0_wlan1: promiscuous mode enabled
ath0: device timeout

Can you recommend a half size mini pcie card or a chipset?
Alternative i can use a usb device.

Thanks!

Also ich habe das Problem, dass nach einer Zwangstrennung nur noch weniger als die Hälfte der Anrufe rein kommen und nach der zweiten Zwangstrennung gar keine mehr.
Dann hilft nur noch ein Neustart der Fritzbox oder der sense.
Ich hatte alles mögliche ausprobiert von Keepalive der Fritzbox über Firewall Modus der sense auf conservative ändern usw.
Bis mir eingefallen ist dass ich "Disable State Killing on Gateway Failure" aktiviert habe, was wohl dazu führt dass die States über die Zwangstrennung hinaus bestehen bleiben.

pftop -f 'port 5060'

PR        DIR SRC                                           DEST                                                   STATE                AGE       EXP     PKTS    BYTES
udp       In  192.168.10.2:5060                             212.227.67.33:3478                               MULTIPLE:MULTIPLE     00:08:52  00:00:48      106     9116
udp       Out 87.123.137.224:5060                           212.227.67.33:3478                               MULTIPLE:MULTIPLE     00:08:52  00:00:48      106     9116
udp       In  192.168.10.2:5060                             212.227.124.130:5060                             MULTIPLE:MULTIPLE     52:06:30  00:00:49    14543  1821202
udp       Out 87.122.91.93:5060                             212.227.124.130:5060                             MULTIPLE:MULTIPLE     52:06:30  00:00:49    14539  1821026
udp       In  192.168.10.2:5060                             212.227.124.129:5060                             MULTIPLE:MULTIPLE     34:02:12  00:00:49     8878   582146
udp       Out 87.123.137.224:5060                           212.227.124.129:5060                             MULTIPLE:MULTIPLE     34:02:12  00:00:49     8878   582146

Ich vermute, dass sowas nach Deaktivieren der Option nicht mehr passiert, allerdings killt er dann halt auch immer States die nichts mit der WAN Seite zu tun haben.
Drum werde ich mir nun einen Cronjob anlegen, der kurz nach der Zwangstrennung die VoIP States killt.
pfctl -k 0.0.0.0/0 -k 212.227.0.0/16