Messages

1

German - Deutsch / Re: Unifi AP und freeRadius auf OPNsense, wie wird es klappen?

« on: October 04, 2024, 09:42:56 pm »

Hallo Neuling10,

ich stehe vor der gleichen Aufgabe, Unifi AP soll sich gegen den OpnSense FreeRadius authentifizieren.
Leider bekomme ich es nicht zum Laufen. Der Unifi AP sendet die Anfrage an den FreeRadius, dieser
bestätigt auch die Anfragen:

Code: [Select]

Auth: (0) Login OK: [74b58****701/74b58****701] (from client Unifi port 0 cli 74-B5-87-**-**-01)
Aber der Client wird trotzdem mit dem WLAN nicht verbunden.

Im Debug-Mode erzählt der Freeafius:

Code: [Select]

(0) Login OK: [74b58****701/74b58****701] (from client Unifi port 0 cli 74-B5-87-**-**-01)
(0) Sent Access-Accept Id 16 from 192.168.5.144:1812 to 192.168.5.242:45820 length 60
(0)   Tunnel-Type = VLAN
(0)   Tunnel-Medium-Type = IEEE-802
(0)   Tunnel-Private-Group-Id = "10"
(0)   Framed-Protocol = PPP
(0) Finished request

Kannst Du Deine Konfiguration hier kurz skizzieren?
Grüße Detlev.

2

German - Deutsch / SIP-Gespräche werden abgebrochen

« on: July 03, 2024, 05:19:52 pm »

Moin,
habe hinter einer OpnSense 22.7 eine Starface hängen. Aktuell werden Gespräche nach ein paar Minuten sporadisch abgebrochen. Eine Anpassung des tcp-aging kann helfen, so der Starafce-Support:
tcp-aging kenne ich vom LAN-Com-Router:

---
TCP-Aging-Minuten
Geben Sie eine Zeit in Minuten an, nach der die TCP-Tabelle automatisch aktualisiert wird, d.h. alle seit der letzten
Aktualisierung nicht mehr angesprochenen Adressen entfernt werden
---

Wo kann ich diese Zeit auf einer OpnSense einstellen?
Grüße Detlev.

3

German - Deutsch / Re: kein Routing von IPV6 ins Internet

« on: March 24, 2024, 07:31:10 pm »

Vodafone Router mit Anschluß über Koax-Kabel, nennt sich bei Vodafone cablemax:

https://www.vodafone.de/festnetz/geschwindigkeit/1000mbits.html

4

German - Deutsch / Re: kein Routing von IPV6 ins Internet

« on: March 24, 2024, 06:53:37 pm »

Danke für die schnelle Antwort.
Das Kabelmodem arbeitet als Router.

Ansonsten musst du dir anschauen, ob dein DHCPv6 Client auf WAN ein Präfix bekommt oder wenn nicht - warum nicht. Erst mit einer GUA sind die Voraussetzungen geschaffen.

Wie kann ich sehen ob der Prefix vom Router zugewiesen wird?

das bekommt mein WLAN Interface vom Router:


ifconfig em1
em1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   description: WAN (wan)
   options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NOMAP>
   ether 00:*:*:*:*:8c
   inet6 fe80::*2:*ff:*ac:*8c%em1 prefixlen 64 scopeid 0x2
   inet6 2a02:*8:*3:*0:*2:*ff:*ac:*8c prefixlen 64 autoconf
   inet 192.168.0.203 netmask 0xffffff00 broadcast 192.168.0.255
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Durch den von Dir verlinkten Beitrag kämpfe ich mich dann morgen mal durch.

Grüße
Detlev.

5

German - Deutsch / kein Routing von IPV6 ins Internet

« on: March 24, 2024, 05:41:13 pm »

Moin Moin,

ich versuche in meinem lokalen Netzwerk ipv6 zu aktivieren.
Ans Internet bin ich über ein Vodafone-Kabelmodem angebunden.

Das WAN-Interface der OpnSense (24.1.4) ist auf DHCPv6 eingestellt, die DHCPv6-Client configuration auf
Basic
Request only an IPv6 prefix: yes
Prefix delegation size: 62
Send IPv6 prefix hint: yes

Damit kann ich von der Opnsense ins Internet Verbindungen aufbauen.
ping / ssh läuft, auch aus dem Internet per ssh auf die Opnsense geht (bei der Vodafone box muß dafür aber noch unter Internet-pv6 exposure die Mac-Adresse, Protokoll und Port eingetragen werden)

Leider kann aber aus dem LAN nicht über ipv6 auf Dienste im Internet zugegriffen werden.

Das LAN-Interface ist auf "Track Interface" eingestellt
Unter Track IPv6 Interface ist als IPv6 Interface WAN konfiguriert,
die Prefix ID steht auf 0,
Manual configuration ist abgeschaltet

In den Firewall-Settings Advanced ist Allow IPv6 aktiviert
 
Mit Wireshark kann ich sehen, dass ein Router Advertisement von der OpnSense zurück kommt.

Der Client (iMac) hat aber nur eine link local unicast Adresse FE80::/10 , müsste hier nicht auch eine global unicast Adresse eingetragen werden? Sonst müsste die OpnSense das Paket doch natten, oder?

netstat -rn liefert auch für beide Interfaces (WAN / LAN ) als Gateway die OpnSense

Internet6:
Destination                             Gateway                                 Flags               Netif Expire
default                                 fe80::**2:**ff:**ac:**88%en0            UGcIg                 en0       
default                                 fe80::**2:**ff:**ac:**88%en1            UGcIg                 en1

aber ein Ping in die schöne ipv6-Welt endet mit einem

ping6 2a02:2e0:3fe:1001:302::
ping6: UDP connect: No route to host

       
Ich habe auf dem LAN-Interface der Opnsene auch IPv4 sowie zwei VLANs mit IPv4 konfiguriert, kann da eventuell das Problem herkommen?
 
Hab aktuell einen Knoten im Kopf, vielleicht hat ja jemand eine Idee.


Grüße Detlev

6

German - Deutsch / IPSEC Tunnel, kein Zugriff vom Opnsense auf das Remote-Netzwerk

« on: November 27, 2023, 12:02:20 pm »

Moin,

ich habe einen VPN Tunnel ( policy-based / IKEv2 ) aufgebaut.

Code: [Select]

ipsec status
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
Security Associations (1 up, 0 connecting):
        con1[18]: ESTABLISHED 4 minutes ago, 92.5x.xx.xx[92.5x.xx.xx]...128.14x.xx.xx[128.14x.xx.xx]
        con1{15}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c55ef6d7_i c820e783_o
        con1{15}:   10.20.150.0/24 === 10.40.0.0/28

OpnSense1
öff. IP 92.5x.xx.xx
lokale IP 10.20.150.135

OpnSense2
öff. IP 128.14x.xx.xx
lokale IP 10.40.0.2

Der Tunnel wird aufgebaut und arbeitet einwandfrei:

Netz  10.20.150.0/24 auf Netz 10.40.0.0/28  ok
Netz  10.20.150.0/24 auf OpnSense 10.40.0.2  ok
OpnSense 10.40.0.2 auf Netz 10.20.150.0/24 nein

Netz 10.40.0.0/28  auf Netz 10.20.150.0/24  ok
Netz 10.40.0.0/28  auf OpnSene 10.20.150.135 ok
OpnSene 10.20.150.135 auf Netz 10.40.0.0/28 nein


Die beiden Opnsense können nicht auf das jeweilige remote-Netz zugreifen.

Die Pakete werden nicht in den Tunnel hineingeroutet, sondern über das WAN-Interface ins Internet

Beispiel:
LAN (em0)       -> v4: 10.20.150.135/24
WAN (re0)       -> v4: 92.5x.xx.xx/29

Code: [Select]

ping 10.40.0.3
PING 10.40.0.3 (10.40.0.3): 56 data bytes


Code: [Select]

tcpdump -ni re0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:55:14.611085 IP 92.5x.xx.xx > 10.40.0.3: ICMP echo request, id 36898, seq 1169, length 64
11:55:15.671079 IP 92.5x.xx.xx > 10.40.0.3: ICMP echo request, id 36898, seq 1170, length 64
11:55:16.731061 IP 92.5x.xx.xx > 10.40.0.3: ICMP echo request, id 36898, seq 1171, length 64

Meine Vermutung: beim Ping auf das remote-Netz 10.40.0.3 nimmt die Opnsense als Quell-Adresse die öff. Adresse und routet somit die Pakte folgerichtig ins Internet. Wie teile ich der OpnSense mit, dass für einen Zugriff auf das Remote-Netz die lokale IP-Adresse der Opnsense benutzt werden soll. Mit diversen Routing-Regeln habe ich schon experimentiert, leider ergebnislos.

Hat jemand eine Idee dazu?

Grüße Detlev.

7

German - Deutsch / Re: OpnSense 23.7 IPSEC Tunnel OpnSense <-> OpnSense

« on: November 27, 2023, 10:18:58 am »

Hi,

wenn auch spät, trotzdem Danke für Deine Unterstützung.
Grüße Detlev.

8

German - Deutsch / Re: OpnSense 23.7 IPSEC Tunnel OpnSense <-> OpnSense

« on: November 03, 2023, 07:43:33 am »

Den Filter bogon- / private- Networks kenne ich, der Haken für private-networks war raus.
Das heißt also, wenn am WAN-Interface priv. Netzwerkadressen erkannt werden, zieht die Firewall automatisch Regeln hoch?

Was mich schon wundert: sobald ich in meinem Szenario ein weiteres Interface konfiguriere, kann ich über das WAN-Interface nicht mehr via https und ssh auf die OpenSense zugreifen. Ich habe aber nirgends eine Konfigurationsmöglichkeit dazu gesehen. Die Sperre kommt aber definitiv von der Firewall, ein pfctl -d auf der Konsole lässt den Zugriff wieder zu, bis zur nächsten Konfigurationsänderung.

wie verhalten sich denn die "Automatically generated rules" ? Die Firewall-Rules werden doch von oben nach unten, bis zum ersten Match abgearbeitet, an erster Stelle steht bei den "Automatically generated rules" ein IPV4 DENY ALL.

Ist hier die Reihenfolge anders?
Was mich   

9

German - Deutsch / Re: OpnSense 23.7 IPSEC Tunnel OpnSense <-> OpnSense

« on: November 02, 2023, 08:19:05 am »

Moin, ich habe die Gateway's in meiner Testumgebung deaktiviert, das macht aber leider keinen Unterschied.
Weiterhin gehen keine Daten durch den Tunnel.

Ich betreibe ja zur Zeit nur ein Testsystem, da kann ich auf das Gateway verzichten, aber dem zukünftigen System (hängt über dem WAN-Port direkt am Internet) kann ich nicht das default-GW am WAN-Port entziehen, wie soll es denn dann eine Verbindung ins Internet auf bauen?

Grüße Detlev.

10

German - Deutsch / OpnSense 23.7 IPSEC Tunnel OpnSense <-> OpnSense

« on: November 01, 2023, 09:30:58 pm »

Hi , ich versuche einen Tunnel zwischen zwei OpnSense Servern aufzubauen, leider mit wenig Erfolg.
Die beiden OpnSense-Server laufen aktuell in einer Virtualisierungsumgebung zum Test.

OpenSense1
WAN 192.168.5.236/24
LAN 10.10.0.0/24

OpenSense2
WAN 192.168.5.246/24
LAN 10.20.0.0/24

Grundsätzlich funktioniert der Tunnelaufbau:

Opnsense1
root@OPNsense1:~ # ipsec status
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
Routed Connections:
        con1{1}:  ROUTED, TUNNEL, reqid 1
        con1{1}:   10.10.0.0/24 === 10.20.0.0/24
Security Associations (1 up, 0 connecting):
        con1[1]: ESTABLISHED 41 minutes ago, 192.168.5.236[192.168.5.236]...192.168.5.246[192.168.5.246]
        con1{6}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c0ff9e58_i c925fab0_o
        con1{6}:   10.10.0.0/24 === 10.20.0.0/24

OpnSense2
root@OPNsense2:~ # ipsec status
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
Routed Connections:
        con1{5}:  ROUTED, TUNNEL, reqid 1
        con1{5}:   10.20.0.0/24 === 10.10.0.0/24
Security Associations (1 up, 0 connecting):
        con1[6]: ESTABLISHED 40 minutes ago, 192.168.5.246[192.168.5.246]...192.168.5.236[192.168.5.236]
        con1{10}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c925fab0_i c0ff9e58_o
        con1{10}:   10.20.0.0/24 === 10.10.0.0/24

in der Firewall ist auf beiden Servern IPSEC für IPv4 komplett geöffnet.

versuche ich von der OpnSense die jeweils andere auf der LAN-IP anzupingen gehen die Pakete über das default-GW auf die Reise und finden leider somit ihr Ziel nicht. Eine entsprechenden Route wurde auf den OpnSense-Servern scheinbar nicht gesetzt

root@OPNsense2:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.5.144      UGS         re0
10.20.0.0/24       link#2             U           re1
10.20.0.1          link#2             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.5.0/24     link#1             U           re0
192.168.5.136      192.168.5.144      UGHS        re0
192.168.5.246      link#1             UHS         lo0

Ich bin momentan etwas ratlos, hat jemand einen Tip für mich, wie ich die Pakte in den IPSEC-Tunnel schaufeln kann?

Im Manual https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn.html steht leider nur zum Schluß 

With the tunnel active, all that remains is to accept traffic on this tunnel using the Firewall->Rules->IPsec menu option.

ich freue mich über jeden hilfreichen Hinweis.

Grüße Detlev

11

General Discussion / Re: routing problem with Virtual IP

« on: January 01, 2021, 12:10:32 pm »

hi,

the problem is solved.
The best hint I've got was from this thread

https://forum.opnsense.org/index.php?topic=11393.0;prev_next=prev#new. by christian.uhlmann.

He discribed the same problem as mine, expect that he has two interfaces in his configuration and not one interface with two addresses.
In former times, I used my opnsense in a multi wan environment. Now, I have only one internet-access-point. So I removed the multi wan Konfiguration from my system.

But the problem was still the same. So I set the opnsene into factory default setting and load my old configuration into the opnsense.

The same problem.

Than I set the opnsense again to factory default and configured the internet connection from the scratch.
It works!
Afterwards I have loaded some single configurations from my backup file into the system (DNS / DHCP / etc )

Conclusion:
No special firewall rules and no special nating is necessary.

But I seems that there are some problem with the removed multi-wan settings , which was not shown in the admin Guy, but saved in the configuration.

Detlev.

12

General Discussion / Re: routing problem with Virtual IP

« on: December 31, 2020, 07:36:23 am »

Hi,

for testing purposes I've disabled my default gateway. Then, everything in my local networks is fine,
the device with an address in the 192.168.5.0/24 network can reach a device in the 192.168.10.0/24 network on the same interface.

But of course, the internet can't be reached.

So I switched back, to reach the internet again.

But why are the packets to the 192.168.10.0/24 routed to the default gateway?
Regards Detlev.

By the way, I've updated Opnsense to OPNsense 20.7.7_1-amd64

 

13

General Discussion / routing problem with Virtual IP [solved]

« on: December 30, 2020, 07:41:50 pm »

Hi,

i have a routing problem with my Opnsense  20.7.5.
My Opnsense has two interfaces

• em0 (LAN)
• igb0 (WAN, connected to a Vodafone Cable Router)

The LAN-Interface has two IP-Addresses, 192.168.5.144/24 and as virtual IP 192.168.10.144/24   
So I can now access from my Opnsense  network devices in both networks. Every thing is fine :-)

But when I try to make a connection from a device with an address of the 192.168.5.0/24 network to an address of the 192.168.10.0/24 network, I've got "Destination Net Unreachable"

A look to the interfaces with tcpdump shows me, the network packets are routed to the gateway via the WAN interface.
But why?

here is my routing table, I think it looks good.

Code: [Select]

ipv4 default 192.168.0.1 UGS 20064533 1500 igb0 UnityMedia
ipv4 127.0.0.1 link#4 UH 1847603 16384 lo0 Loopback
ipv4 192.168.0.0/24 link#2 U 20070144 1500 igb0 UnityMedia
ipv4 192.168.0.100 link#2 UHS 784634 16384 lo0 Loopback
ipv4 192.168.5.0/24 link#1 U 309115708 1500 em0 LAN
ipv4 192.168.5.144 link#1 UHS 2963429 16384 lo0 Loopback
ipv4 192.168.10.0/24 link#1 U 38871 1500 em0 LAN
ipv4 192.168.10.144 link#1 UHS 8 16384 lo0 Loopback

I think, the device with the network-address of the 192.168.5.0/25 network has to get an ICMP-Redirect, because the destination network 192.168.10.0/24 is on the same link. But where can I set this ?

Any idea, or am I completely wrong?

Greeting Detlev.

14

General Discussion / Re: Port nating

« on: February 17, 2019, 05:15:38 pm »

Hi Bart,

thanks for your answer. I Think in this case, it's just the same: target interface address and target vigor address.

Bye
Detlev.

15

General Discussion / Port nating

« on: February 17, 2019, 01:12:02 pm »

Hi,
i have a Vigor 130 as vdsl+ Modem on my opnsense connected to the interface igb0.
So i configured a point-to-point Interface on the physical interface igb0. Everything works fine :-)

The vigor has an administration-interface at the ip 192.168.1.1 and i want to reach this interface from my local network 192.168.5.0/24.

For this purpose i switched the Outbound-NAT (Firewall: NAT: Outbound) from "Automatic outbound NAT rule generation" to "Hybrid outbound NAT rule generation" and added an new rule:

Interface   Source   Source Port   Destination      Destination Port   NAT Address      NAT Port   Static Port   Description   
Vigor      LAN net   *         Vigor net      *               Vigor address   *         NO

Vigor.: Interface igb0
LAN net. : 192.168.5.0/24
Vigor net : 192.168.1.0/24

but i can't reach the vigor.
Then i changed the Destination from Vigor-Net to the ip of the vigor and it worked.

Vigor      LAN net   *         192.168.1.1/32   *               Vigor address   *         NO          

Then i changed the destination from 192.168.1.1/32 to 192.168.1.0/24, and it worked too.

So im confused, isn't the destination "Vigor net" similar to the network-address 192.168.1.0/24

Thanks for every explanation.

Detlev.