Topics

1

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.

2

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

3

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.

4

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

5

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.

6

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.