1
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 05, 2019, 04:36:49 pm »
... also hat niemand eine Idee?
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.
Pages: [1] 2
2
German - Deutsch / Re: DNS Server mit mehreren Domains
« on: August 02, 2019, 11:55:10 am »
Hallo,
ich habe irgendwo mal gelesen, dass "multiple DNS" auf der Roadmap stehen oder zumindest für irgendwann angedacht sind.
Getrennte Netze verstehe ich, aber welche Vorteile erhoffst du dir durch eine DNS Trennung?
LG
ich habe irgendwo mal gelesen, dass "multiple DNS" auf der Roadmap stehen oder zumindest für irgendwann angedacht sind.
Getrennte Netze verstehe ich, aber welche Vorteile erhoffst du dir durch eine DNS Trennung?
LG
3
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 02, 2019, 11:17:11 am »
Ok, also ich hab mir das über die "Paketaufzeichnung"s-Funktion mal angesehen.
Wenn ich am Quell-Host (172.16.128.1) einen Ping, Porttest oder sonst was über das Gateway (172.16.128.2) an das GW-Interface (192.168.2.1) sende, wird NICHTS aufgezeichnet ... da geht scheinbar nichts über das OpenVPN-Interface hinaus! und der Ping wird durch 127.0.0.1 beantwortet?
Wenn ich aber einen Ping vom GW-Interface (192.168.2.1) an 172.16.128.1 sende, kommt das Paket am richtigen Host an und der Reply kommt auch zurück!
NAT wurde für die betroffenen Schnittstellen keines definiert, siehe Screenshots im Anhang!
Welcher Mechanismus / welches Setting könnte bewirken, dass ein Host den ausgehenden PING selbst mit 127.0.0.1 beantwortet, wenn er selbst kein Interface oder VIP mit der Ziel-IP hat, obwohl er aber eine Route zu dem Ziel in seiner Table hat und die FW nichts blockiert?
Ich habe es auch mit einer VIP mit der Ziel-IP am Quell-Host versucht, um den gegen Check zu machen. Hier wird der PING klarerweise lokal beantwortet, jedoch steht dann die Ziel-IP im Reply und nicht die Loopback-IP.
Hier auch nochmal beide Routing-Tables:
von 172.16.128.1:
von 172.16.128.2 / 192.168.2.1:
Ich bin ehrlich planlos, was dieses Verhalten noch auslösen könnte!
Vielen Dank, für alle Ideen die eingebracht werden.
LG
Wenn ich am Quell-Host (172.16.128.1) einen Ping, Porttest oder sonst was über das Gateway (172.16.128.2) an das GW-Interface (192.168.2.1) sende, wird NICHTS aufgezeichnet ... da geht scheinbar nichts über das OpenVPN-Interface hinaus! und der Ping wird durch 127.0.0.1 beantwortet?
Wenn ich aber einen Ping vom GW-Interface (192.168.2.1) an 172.16.128.1 sende, kommt das Paket am richtigen Host an und der Reply kommt auch zurück!
NAT wurde für die betroffenen Schnittstellen keines definiert, siehe Screenshots im Anhang!
Welcher Mechanismus / welches Setting könnte bewirken, dass ein Host den ausgehenden PING selbst mit 127.0.0.1 beantwortet, wenn er selbst kein Interface oder VIP mit der Ziel-IP hat, obwohl er aber eine Route zu dem Ziel in seiner Table hat und die FW nichts blockiert?
Ich habe es auch mit einer VIP mit der Ziel-IP am Quell-Host versucht, um den gegen Check zu machen. Hier wird der PING klarerweise lokal beantwortet, jedoch steht dann die Ziel-IP im Reply und nicht die Loopback-IP.
Hier auch nochmal beide Routing-Tables:
von 172.16.128.1:
Code: [Select]
ipv4 172.16.128.0/24 link#7 U 968441 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 81 16384 lo0
ipv4 172.16.128.2 00:bd:a0:1c:ff:04 UHS 8311 1500 ovpns4 LAN
ipv4 192.168.2.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 6 1500 ovpns4 LAN
von 172.16.128.2 / 192.168.2.1:
Code: [Select]
ipv4 default 192.168.4.1 UGS 983880 1500 igb2 WAN
ipv4 127.0.0.1 link#4 UH 2166 16384 lo0
ipv4 172.16.128.0/24 link#8 U 973370 1500 ovpnc1 ULK
ipv4 172.16.128.2 link#8 UHS 0 16384 lo0
ipv4 192.168.1.0/24 172.16.128.1 UGS 0 1500 ovpnc1 ULK
ipv4 192.168.2.0/24 link#2 U 0 1500 igb1 Core
ipv4 192.168.2.1 link#2 UHS 0 16384 lo0
ipv4 192.168.3.0/24 link#1 U 3259080 1500 igb0 LAN
ipv4 192.168.3.1 link#1 UHS 0 16384 lo0
ipv4 192.168.4.0/24 link#3 U 985453 1500 igb2 WAN
ipv4 192.168.4.100 link#3 UHS 0 16384 lo0
Ich bin ehrlich planlos, was dieses Verhalten noch auslösen könnte!
Vielen Dank, für alle Ideen die eingebracht werden.
LG
4
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 02, 2019, 09:44:20 am »
Hat vielleicht noch jemand eine Idee, woran das liegen könnte?
5
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 01, 2019, 04:03:30 pm »
Interessanterweise klappt das ganze, wenn ich den PING in verkehrter Richtung aussende.
Wenn ich am Ziel-Host, mit einem der Interfaces die sonst nicht erreichbar sind, einen Ping an den Quell-Host sende, schafft er es den Reply zurück zu senden.
Wenn ich am Ziel-Host, mit einem der Interfaces die sonst nicht erreichbar sind, einen Ping an den Quell-Host sende, schafft er es den Reply zurück zu senden.
6
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 01, 2019, 02:44:58 pm »
Hier auch noch die Routing-Table vom Ziel-Host:
... der ICMP-Reply an 172.16.128.1 müsste über das gleiche Interface zurück gehen, wo der Request hergekommen ist!
... der ICMP-Reply an 172.16.128.1 müsste über das gleiche Interface zurück gehen, wo der Request hergekommen ist!
7
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 01, 2019, 02:41:14 pm »
Ja, das läuft problemlos!
... nur wenn ich versuche eine der anderen Interfaces zu pingen, ... geht es nicht über den OpenVPN Link, sondern wird lokal beantwortet.
Auf dem Quell aber auch auf dem Ziel-Host ist ICMP auch generell gestattet!
Dank dir für deine Hilfe!
... nur wenn ich versuche eine der anderen Interfaces zu pingen, ... geht es nicht über den OpenVPN Link, sondern wird lokal beantwortet.
Auf dem Quell aber auch auf dem Ziel-Host ist ICMP auch generell gestattet!
Dank dir für deine Hilfe!
8
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 01, 2019, 01:27:03 pm »
Hallo,
nur begrenzt!
Es gibt 3 Portweiterleitungen von der externen IP auf interne Services, siehe Screenshot im Anhang.
Und 2 ausgehende Regeln, sofern die FW als Gateway ins Internet bzw ins "ULK" Netz verwendet wird (trifft in dieser Situation nicht zu!).
Virtuelle IP-Adressen sind keine definiert!
LG
nur begrenzt!
Es gibt 3 Portweiterleitungen von der externen IP auf interne Services, siehe Screenshot im Anhang.
Und 2 ausgehende Regeln, sofern die FW als Gateway ins Internet bzw ins "ULK" Netz verwendet wird (trifft in dieser Situation nicht zu!).
Virtuelle IP-Adressen sind keine definiert!
LG
9
German - Deutsch / Re: Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: August 01, 2019, 10:52:46 am »
Ich habe jetzt noch Versucht die Situation schematisch darzustellen. ... Vielleicht kann mir ja jemand mit einer Idee weiterhelfen!?
Code: [Select]
WAN / Internet
:
:
:
.-----:-------.
| OPN:sense |
| (Br:dge) |
'-----:-------'
| 172.16.128.1/24
|
|
LAN | OpenVPN
|
|
| 172.16.128.2/24
.-----:-------.
| OPN:sense | 192.168.4.0/24
| (Br:dge) +------------------------+> Default-GW / 192.168.4.1 ---> Internet
'+----+-------'
| |
| |
| | 192.168.3.0/24
|
| 192.168.2.0/24
10
German - Deutsch / Probleme mit statischen Routen seit Upgrade auf 19.7.1
« on: July 31, 2019, 11:24:42 am »
Hallo Leute,
ich habe 2 OPNsense Hosts über OpenVPN mit einander verbunden. Am 1sten (DMZ) habe ich einen OpenVPN-Server und NGINX reverse Proxy, am 2ten (OpenVPN-Client) mehrere physikalische Subnetze.
Für die Erreichbarkeit der Subnetze habe ich am ersten Host die OpenVPN - Client IP Adresse (172.16.128.2) als Gateway eingetragen und darauf die Subnetze (192.168. ... ) als Routen angelegt.
Vor dem Upgrade hat diese Konfig wunderbar funktioniert, wenn ich jetzt aber versuche am ersten Host einen PING auf ein Subnetz-Interface vom 2ten abzusetzen, bekomme ich folgendes:
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.079 ms
... der erste Host antwortet selbst auf den ECHO Request!???
Hier noch die Routing-Table vom ersten Host:
ipv4 127.0.0.1 link#2 UH 58014 16384 lo0
ipv4 172.16.128.0/24 link#7 U 1459050 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 69 16384 lo0
ipv4 192.168.2.0/24 172.16.128.2 UGS 3 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
Wenn ihr eine Idee habt, woran das liegen könnte, wäre ich sehr Dankbar!
LG,
Mophi
ich habe 2 OPNsense Hosts über OpenVPN mit einander verbunden. Am 1sten (DMZ) habe ich einen OpenVPN-Server und NGINX reverse Proxy, am 2ten (OpenVPN-Client) mehrere physikalische Subnetze.
Für die Erreichbarkeit der Subnetze habe ich am ersten Host die OpenVPN - Client IP Adresse (172.16.128.2) als Gateway eingetragen und darauf die Subnetze (192.168. ... ) als Routen angelegt.
Vor dem Upgrade hat diese Konfig wunderbar funktioniert, wenn ich jetzt aber versuche am ersten Host einen PING auf ein Subnetz-Interface vom 2ten abzusetzen, bekomme ich folgendes:
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.079 ms
... der erste Host antwortet selbst auf den ECHO Request!???
Hier noch die Routing-Table vom ersten Host:
ipv4 127.0.0.1 link#2 UH 58014 16384 lo0
ipv4 172.16.128.0/24 link#7 U 1459050 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 69 16384 lo0
ipv4 192.168.2.0/24 172.16.128.2 UGS 3 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
Wenn ihr eine Idee habt, woran das liegen könnte, wäre ich sehr Dankbar!
LG,
Mophi
11
General Discussion / Re: OPNsense running on a rented VPS -> 1 WAN-Interface, multiple tun/tap-Interfaces
« on: September 05, 2018, 05:09:18 pm »
Hi,
no, they don't!
But it is possible to assign the Interfaces with the CLI. Thank you "Mann-IT" for the hint!
I'm convinced, this is still a BUG in the GUI!
Kind regards,
Mophi
no, they don't!
But it is possible to assign the Interfaces with the CLI. Thank you "Mann-IT" for the hint!
I'm convinced, this is still a BUG in the GUI!
Kind regards,
Mophi
12
German - Deutsch / Re: OPNsense auf VPS -> 1 phys. WAN Interface, mehrere "interne" tun/tap Interfaces
« on: September 05, 2018, 05:05:30 pm »
Hallo,
ich bin begeistert, über den Weg hat das tatsächlich funktioniert.
Vielen lieben Dank für den Tipp!
LG
... Ich halte das dennoch für einen BUG in der GUI!
ich bin begeistert, über den Weg hat das tatsächlich funktioniert.
Vielen lieben Dank für den Tipp!
LG
... Ich halte das dennoch für einen BUG in der GUI!
13
General Discussion / Re: OPNsense running on a rented VPS -> 1 WAN-Interface, multiple tun/tap-Interfaces
« on: August 31, 2018, 07:55:52 am »
Hi Bart,
thank you for your help, but that doesn't work for me!
I did your recommendation, added a VLAN with WAN as parent and assigned it as LAN-Interface (with prevent from removal).
Afterwards i wanted to assign one tap-Device as "VPN"-Interface, but when i push "+" the Device of LAN-Interface changes from VLAN-Device to the tap-Device, instead of creating a new Interface with the tap, which i wanted to define with name "VPN".
Do you have any other ideas?
thank you for your help, but that doesn't work for me!
I did your recommendation, added a VLAN with WAN as parent and assigned it as LAN-Interface (with prevent from removal).
Afterwards i wanted to assign one tap-Device as "VPN"-Interface, but when i push "+" the Device of LAN-Interface changes from VLAN-Device to the tap-Device, instead of creating a new Interface with the tap, which i wanted to define with name "VPN".
Do you have any other ideas?
14
German - Deutsch / Re: OPNsense auf VPS -> 1 phys. WAN Interface, mehrere "interne" tun/tap Interfaces
« on: August 31, 2018, 07:44:15 am »
Hallo,
ja es wäre denkbar, dass es am fehlenden physischen LAN-Adapter liegt.
Virtuelle-Adapter (auch reboot beständige) können wir ja erzeugen. Das VLAN am WAN Adapter bliebt bei einem reboot erhalten und lässt sich auch alternativ dem LAN-Interface zuordnen.
Die virtuellen OpenVPN-Adapter gehen bei einem reboot zwischenzeitlich verloren, aber die Schnittstellen-Zuordnung sollte persistent bleiben, was sie auch tut wenn man nur ein einziges tun/tap-zugewiesen hat bzw. mit "Lock - prevent interface removal" arbeitet.
Der Bug liegt wo möglich an der Stelle, wie mit Interface-Typen umgegangen wird. ... möglicherweise werden virtuelle Adapter bei der Schnittstellen-Zuordnung anders behandelt wie physische.
... Ich konnte nach wie vor keinen funktionierenden Workaround finden
!
ja es wäre denkbar, dass es am fehlenden physischen LAN-Adapter liegt.
Virtuelle-Adapter (auch reboot beständige) können wir ja erzeugen. Das VLAN am WAN Adapter bliebt bei einem reboot erhalten und lässt sich auch alternativ dem LAN-Interface zuordnen.
Die virtuellen OpenVPN-Adapter gehen bei einem reboot zwischenzeitlich verloren, aber die Schnittstellen-Zuordnung sollte persistent bleiben, was sie auch tut wenn man nur ein einziges tun/tap-zugewiesen hat bzw. mit "Lock - prevent interface removal" arbeitet.
Der Bug liegt wo möglich an der Stelle, wie mit Interface-Typen umgegangen wird. ... möglicherweise werden virtuelle Adapter bei der Schnittstellen-Zuordnung anders behandelt wie physische.
... Ich konnte nach wie vor keinen funktionierenden Workaround finden
!
15
German - Deutsch / Re: OPNsense auf VPS -> 1 phys. WAN Interface, mehrere "interne" tun/tap Interfaces
« on: August 29, 2018, 11:56:51 am »
Hallo Mario,
vielen Dank für deine Nachricht! ... beruhigt mich zu hören, dass nicht nur mir so geht.
@all:
Ich habe jetzt auch einen englischen Eintrag dazu eröffnet um die Chancen auf einen Workaround oder Bug-Fix zu erhöhen: https://forum.opnsense.org/index.php?topic=9541.0
Falls jemand eine Idee hat, sie wäre willkommen!
LG,
Mophi
vielen Dank für deine Nachricht! ... beruhigt mich zu hören, dass nicht nur mir so geht.
@all:
Ich habe jetzt auch einen englischen Eintrag dazu eröffnet um die Chancen auf einen Workaround oder Bug-Fix zu erhöhen: https://forum.opnsense.org/index.php?topic=9541.0
Falls jemand eine Idee hat, sie wäre willkommen!
LG,
Mophi
Pages: [1] 2