Ja Philipp, kann sein das ich das auch schon so erlebt habe, siehe hier:https://forum.pfsense.org/index.php?topic=58700.msg482763#msg482763
Da steht auch drin wie man diesen Fehler abstellt und weitermacht. Gelöst ist es aber nicht, hierzu ist der Beitrag von marcelloc hier recht aussagekräftig:
https://forum.pfsense.org/index.php?topic=87782.msg483244#msg483244

Also mein Fazit ist das es mit Proxy und sso bei pfsense momentan ganz schlecht aussieht. Würd mich aber sehr freuen wenn jemand meinem Fazit widerspricht!

Gruß Alex

Und hier ist die Lösung für das Problem:
https://forum.pfsense.org/index.php?topic=73988.msg487813#msg487813

Wir können das Thema schließen.
Der endgültige Praxistest steht zwar noch aus aber die ersten Tests waren alle erfolgreich. Sowohl Multiwan auf Basis von bestimmten Rules (Nutzung von beiden Leitungen auf Portbasis) als auch die Traffic Shaping Geschichte.

Danke an flix87 für seine Unterstützung.

Hier meine Switch Config:

sh running-config Building configuration... Current configuration : 1418 bytes ! version 12.1 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Peter ! ! ip subnet-zero ! ip ssh time-out 120 ip ssh authentication-retries 3 ! spanning-tree mode pvst no spanning-tree optimize bpdu transmission spanning-tree extend system-id ! ! ! ! interface FastEthernet0/1 ! interface FastEthernet0/2 switchport access vlan 10 switchport mode access ! interface FastEthernet0/3 switchport access vlan 10 switchport mode access ! interface FastEthernet0/4 switchport access vlan 10 switchport mode access ! interface FastEthernet0/5 switchport access vlan 10 switchport mode access ! interface FastEthernet0/6 switchport access vlan 20 switchport mode access ! interface FastEthernet0/7 switchport access vlan 20 switchport mode access ! interface FastEthernet0/8 switchport access vlan 20 switchport mode access ! interface FastEthernet0/9 switchport access vlan 20 switchport mode access ! interface FastEthernet0/10 ! interface FastEthernet0/11 switchport mode trunk ! interface FastEthernet0/12 switchport mode trunk ! interface Vlan1 ip address 192.168.1.2 255.255.255.0 no ip route-cache ! interface Vlan10 no ip address no ip route-cache shutdown ! interface Vlan20 ip address 192.168.20.2 255.255.255.0 no ip route-cache shutdown ! ip http server ! line con 0 line vty 0 4 login line vty 5 15 login ! ! end

Eine Fritz!box (192.168.178.1) ist an WAN mit Static IPv4 192.168.178.254 angeschlossen.
IPv4 Upstream Gateway hab ich 192.168.178.1 eingetragen.
Ich hab den pfSense an den Port 12 angeschlossen und den Accesspoint an Port 11.

Ein Testrechner an Port 1 erhält vom DHCP die IP 192.168.1.x
Das Internet funktioniert, alles top. Kann die FritzBox auf 192.168.178.1 nicht erreichen, gut.
Ich kann die pfSense Oberfläche erreichen.
Ein Testrechner an Port 4 erhält vom DHCP die IP 192.168.10.x
Internet funktioniert nicht, kann auch den pfSense auf 192.168.10.1 nicht erreichen.

Der Accesspoint ist in VLAN10 und VLAN20 erreichbar
192.168.10.3 und 192.168.20.3, kann auch von einem Client der am Switch hängt darauf zugreifen.

Muss ich bei den VLAN Interfaces noch ein Gateway eintragen, damit das Internet funktioniert, oder sind noch weitere Firewallregeln erforderlich?

Kann ich bestätigen mit der Anpassung von NAT läuft Telekom Voip mit einem Gigaset dx800a ohne Probleme

Der Thread ist zwar schon ein wenig älter, aber steht ja noch nicht auf Gelöst:

So eine Konfig betreibe ich auch:

pfsense 1: xx.xx.xx.2
pfsense 2: xx.xx.xx.3
WAN-CARP: xx.xx.xx.4

die xx.xx.xx.5 brauchst Du nicht.

Die Regel

Protokoll IPv4/UDP SOURCE any Port any -> DEST CARP_IP5  Port 1194 ACCEPT

ist ok, nur eben auf die IP xx.xx.xx.4. Bei mir ist das zwar TCP/443, weil wir auch aus Proxy-Netzen drankommen müssen, aber das spielt in diesem Kontext ja keine Rolle.

Damit OpenVPN auf die virtuelle IP hört, musst Du bei 'Advanced configuration' den Eintrag

local xx.xx.xx.4

machen. Dann läuft das.

Habe herausgefunden dass der TP-LINK TL-WR710N  das auch kann  :)

Da ich da auch festgehangen habe mit dem Vigor 130:

Folgende Einstellungen waren nötig:

1. Unter "Internet Access>>PPPoE/PPPoA" wurde der PPPoE/PPPoA Client disabled
2. Unter "Internet Access>>MPoA / Static or dynamic IP" muss man
a) MPoA (RFC1483/2684) aktivieren
b) VPI=1 und VCI=32 setzen
c) Bridge Mode einschalten

Nein, es sind keine Device-Ids in der fstab. Daher ist das Skript ja auch nicht erforderlich. Es arbeitet ja nur mit Device-Ids.

Ich habe den Upgrade-Guide nochmal gelesen:

ATA disks are labeled as /dev/adaX rather than /dev/adX. […] For a full install, running /usr/local/sbin/ufslabels.sh before the upgrade will convert /etc/fstab to UFS labels rather than disk device names bypassing any device name issues that could arise due to the switch.

Solange also keine Device-Ids in der fstab stehen, ist das gar kein Problem.

Und Du hast recht: Der Upgrade-Guide ist da nicht ausreichend genau.

-flo-

über einen GRE Tunnel (OpenVPN) mit B verbunden ist.

Möp. Das kann nicht sein. ;) Entweder der Tunnel ist GRE - dann ist sehr wahrscheinlich IPSEC im Spiel, oder es ist OpenVPN, dann hat das mit GRE rein gar nichts zu tun. Was von beidem ist denn nun im Einsatz?

Wenn du jetzt noch sagst, an was es denn lag und wie du es hinbekommen hast, wäre uns anderen auch damit geholfen ;)

@peer_g:

Nee. da tuts auch eine dicke Fritzbox.

Nur zur Vollständigkeit, weil hier wahrscheinlich nicht nötig: Wenn man nur "alte" (keine IP) Telefone hat, tuts auch eine uralte FB. Ich mache das mit einer 5050 und zwei analogen Telefonen.

-flo-

Hi Chris,
ist mal nur als Denkanstoß gedacht und muss nicht zwingend nachgemacht werden.
Bei mir läuft eine 7490 in vorderster Front am DSL.
Fritte
LAN      192.168.219.0/24
DHCP
LAN-Abgang zum pfSense-WAN erhält immer die gleiche IP 192.168.219.2 .
USB-Drucker an der Fritte.
TV, Android-Handy und Gäste-LAN
pfSense (auf ALIX-Board)
WAN      192.168.219.2
LAN        192.168.159.0/24 
DMZ      172.16.10.0/24
WLAN    192.168.89.0/24
Also keine Verbindung aus dem ersten Netz, Gäste, Handy auf die LAN-Geräte. Für DMZ ein Portforwarding.
Ausserdem laufen da noch OpenVPN-Server auf der pf. (Portforwarding auf der Fritte.
Gruß orcape

Hallo JeGr,

super Tipp - das war's. Vielen Dank.
Das Nat stand plötzlich auf "Manual" - richtig wäre "Hybrid Outbound NAT rule generation".
Jetzt klappt's wieder :-)

Gruß Thorsten

Jepp, alles zu, alles verboten.

Alles andere wäre für ein Gerät das Sicherheit verspricht wohl Unsinn

zu den NIC
meine Fritzbox geht einmal auf einen Switch einmal Server
und vom Switch geht es auch auf den Server
Ist klar ist nicht wirklich redundant und ich kann es auch trennen.

…nun, so richtig gibt das für mich keinen Sinn.
2 WAN-NIC´s am Server (pfSense) die wie auch immer im LAN der Fritte hängen.
VLAN´s mit gleicher Netzwerkadresse wie das LAN der Fritte...

10.147.42.0/?

…fehlt eigentlich nur noch die Netzmaske 255.0.0.0, um das Kraut fett zu machen.
Sorry, ich glaube Du solltest Dich noch mal eingehend mit den Grundlagen auseinandersetzen und die Netzstruktur überarbeiten.
Ich habe bei mir eine ähnliche Struktur, allerdings ohne VLAN´s.
Versuche die Netze ordentlich zu trennen (gibt genügend private IP´s), das hilft dann auch bei der Fehlersuche.
Switch im Fritten-LAN wenn nötig, Ok.
Von da eine 2. Verbindung zur pfSense-WAN ????
Richte Dir auf dieser NIC lieber eine Demilitarisierte-Zone für Dein NAS ein, das wäre sinnvoller.
Gruß orcape