SASL authentication failed; no mechanism available

Hi, mit Telnet checken welche AUTH typen unterstützt werden:

http://www.postfix.org/SASL_README.html#server_test

dann angezeigten mechanism probieren

http://www.postfix.org/postconf.5.html#smtp_sasl_mechanism_filter

smtp_sasl_mechanism_filter = plain

oder

smtp_sasl_mechanism_filter = plain, login

usw.

Gruß

hallo jegr,

danke für tipp mit logfiles durchschauen, da hätte ich auch selbst drauf kommen können.
musste seltsamerweise trotz aktiver dmz-funktion am router vor dem pfsense auch den openvpn-port extra nochmals port-forwarden, jetzt gehts.

liebe grüße ferdinand

Hi,

habe bei Microsoft ein Dokument gefunden, welches grob schildert, mit welchen Metriken das OS die Internetkonnektivität zu bestimmen versucht: http://blogs.technet.com/b/networking/archive/2012/12/20/the-network-connection-status-icon.aspx

Die Kurzform:

DNS-Query für www.msftncsi.com

HTTP-GET auf http://www.msftncsi.com/ncsi.txt

DNS-Query (A) für dns.msftncsi.com

DNS-Query (AAAA) für dns.msftncsi.com

Wäre also gut möglich, dass einer der o.g. Punkte bei deinen Windows 7-Clients nicht erfolgreich durchgeführt werden kann. Schau doch mal per nslookup, ob du die DNS-Anfragen manuell durchführen kannst.

Gruß

DANKE, werde ich dann teste :-)

Hallo

Hab den APU2B4 erfolgreich installiert und ist von 12.30-15.30 Uhr gelaufen. Doch um 15.30 Uhr wieder das gleiche Problem wie beim APU1D4 die LAN-Verbindung ist einfach abgebrochen.
Hier mal ein Bild. Wie gesagt der Switch ist neu, das Ethernet-Kabel ebenfalls und die letzten 2 Tage ist alles mit dem Linksys EA6700 wunderbar gelaufen.
Ich vermute, dass das Update auf 2.2.6 irgendwie nicht ganz gelaufen ist wie es sollte. Kann man auf 2.2.5 downgraden, oder hat jemand vielleicht einen Tipp an was es liegen könnte?
Auf jeden Fall habe ich jetzt den APU2B4 vergebens gekauft.

Danke für Deine Anteilnahme  ;)

Ja, ich. Alle drei genannten erreichen quasi die Maximalgeschwindigkeit an einem 100/40 Anschluss. Der 723V war beim Download ungefähr 5 Mbit langsamer, was aber auch an der Auslastung des Servers gelegen haben kann.

Das macht den 723V für mich so interessant. Wo sonst gibts 100/40 für 30 Euro?

Okay, du möchtest, dass RADIUS über die Router arbeitet.
Da hast du wohl absolut nichts davon, dass du das Webinterface freigibst. Ich denke nicht, dass du allen deinen Radius Clients erst beibringen möchtest, dass über Port 443 mit dem Server kommunizieren sollen.

Klar ist es möglich, dass sich externe Clients am Server anmelden, wenn sie ihn erreichen.

Radius arbeitet, soweit ich informiert bin auf den UDP Ports 1812 u. 1813.
Diese Port und dieses Protokoll musst du auf der pfSense am WAN per Firewallregel öffnen und ebenso auf der FB zur pfSense durchschleifen.

Die WebGUI der pfSense braucht dann gar nicht von außen geöffnet werden. Wäre besser so.

Hallo Michael,

du weißt schon, dass du reale routingfähige IP Adressen im internen Netz benutzt, die dir nicht gehören? Und noch dazu Netze, die ggf. wichtig sind oder sein können (192.0.0.0/29)? Ich würde erst einmal meine LAN Netze aufräumen und mit ordentlichen IP Adressbereichen versorgen, die nicht zu irgendwelchen Konflikten führen können.

Zitat: "Addresses starting with "192.0.0." are reserved for a variety of different protocols by the IETF, the organization that develops Internet protocols.  The common factor is that these addresses are not used by a single organization but by any network where the specific protocol is implemented." Insbesondere 192.0.0.0/29 wird für DS Lite benutzt, aus solchen Adressblöcken würde ich also tunlichst herausbleiben.

Zur eigentlichen Frage: dazu müsstest du eine zusätzliche Phase 2 bei IPSec auf beiden Seiten spezifizieren mit dem entsprechenden Adressbereich, der funktionieren soll. Das könnte auf der FB durchaus schwerer zu realisieren sein, da ich nicht weiß ob deren seltsamer VPN Wizzard mehrere Phasen überhaupt unterstützt oder ob das händisch in die Konfiguration eingebaut werden muss.

Grüße

@l4k3k3m4n:

Versuch mal das hier:

https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP%2C_use_syslog%2C_NTP%2C_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F

Genau das war es gewesen! Nun läuft es :)
Danke dir!

Das sollte helfen:
https://doc.pfsense.org/index.php/Wildcard_Records_in_DNS_Forwarder/Resolver

Leider bin ich mit der pfSense nicht zum Erfolg gekommen. Ich habe keinen Weg gefunden den "Ausgang" des Remoten WLAN-Controllers zu einem LAN-Port der Internet-pfSense zu tunneln.
Meine Lösung ist daher an den remoten Standorten ebenfalls pfSenses einzusetzen und diese dann vom WAN-Interface aus per OpenVPN-Tunnel zum LAN-Interface der Internet-pfSense zu führen. Anders weiss ich mir nicht zu helfen… finde die Lösung aber richtig doof, da ich die Captive-Portal User dann über viele pfSenses verstreut habe...

…danke.

Hab's gestern schon gesehen, gleich probiert und es rennt wieder wie es soll.

-Wanninger

Teuer ist relativ. Wie schon so oft zitiert: you get what you pay for. Zudem steht bei der Delock Karte nun mal gar nichts dabei, was für ein NIC und Chipsatz verwendet wird. Da die meiste Welt lediglich Windows im Hirn hat, bringt dir das erstmal für pfSense/FreeBSD gar nichts. Durch ein wenig suchen findet man dann eine unspezifizierte Angabe von "Realtek" als NIC. Heißt, das kann laufen, muss aber nicht, je nachdem welcher Realtek Chip hier verbaut wurde und ob der im Treibervorrat von FreeBSD 10 enthalten ist. Solche Puzzlespiele sind mir ein wenig zu dumm, wenns um das Wichtigste in einem Router geht - Netzwerkdurchsatz und -verfügbarkeit. Und da haben Intel Chipsätze bei Netzwerkkarten eben am wenigsten Probleme, weshalb die auch immer vorgezogen werden.

Klassischerweise konfigurieren die Unis ein Profil für den Cisco VPN Client in welchem normalerweise auch Dinge wie Verbindungsdauer etc. festgehalten werden. Diese Konfiguration ist nicht für einen VPN Tunnel gedacht. Zudem möchte eine Uni selten, dass du mit deinen persönlichen VPN Zugangsdaten einen Tunnel für multiple Clients dahinter aufmachst. Davon abgesehen, kann es sein, dass hier nicht nur reines IPSEC zum Einsatz kommt, sondern etwaige Einstellungen aus dem Client benötigt werden, was ich dir aber nicht sagen kann, da ich weder Uni noch Konfiguration kenne.

Wenn du dazu keinen Streß mit deinem Uni RZ haben möchtest, würde ich davon abraten, dich mit deinen VPN Client Zugangsdaten (für deinen Einzelclient) als Tunnel/Routed VPN verbinden zu wollen. Die meisten IT'ler der RZs reagieren auf sowas nicht wirklich gut. Zudem kann es sein dass so oder so ein Disconnect erzwungen wird nach Zeit x.

Moin,

nur mal so, das spukt das Zyxel VMG1312-B30A so über die DSL Leitung aus:

============================================================================     VDSL Training Status:  Showtime                     Mode:  VDSL2 Annex B             VDSL Profile:  Profile 17a             Traffic Type:  PTM Mode             Link Uptime:  19 days: 10 hours: 13 minutes ============================================================================       VDSL Port Details      Upstream        Downstream               Line Rate:      4.068 Mbps      29.031 Mbps     Actual Net Data Rate:      4.044 Mbps      28.982 Mbps           Trellis Coding:        ON                ON               SNR Margin:        8.5 dB            8.3 dB             Actual Delay:          8 ms              8 ms           Transmit Power:        2.4 dBm          13.2 dBm           Receive Power:      -6.8 dBm          -8.9 dBm               Actual INP:        1.0 symbols      1.0 symbols       Total Attenuation:        8.6 dB          22.1 dB Attainable Net Data Rate:      4.212 Mbps      30.130 Mbps ============================================================================       VDSL Band Status    U0      U1      U2      U3      D1      D2      D3   Line Attenuation(dB):  6.5    37.2    53.2    N/A    20.8    50.4    76.4  Signal Attenuation(dB):  6.5    37.0    N/A    N/A    20.8    50.0    N/A          SNR Margin(dB):  9.0    8.4    9.0    N/A    8.3    8.3    N/A    Transmit Power(dBm):- 0.4  - 2.4  - 3.4    N/A    11.8    7.4    N/A  ============================================================================             VDSL Counters           Downstream        Upstream Since Link time = 13 min 35 sec FEC: 9586358 6688150 CRC: 169 0 ES: 84 106 SES: 0 0 UAS: 0 4104 LOS: 0 124 LOF: 0 124 LOM: 0 0 Latest 15 minutes time = 12 min 2 sec FEC: 81 0 CRC: 0 0 ES: 0 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Previous 15 minutes time = 15 min 0 sec FEC: 72 0 CRC: 0 0 ES: 0 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Latest 1 day time = 4 hours 27 min 2 sec FEC: 6269 0 CRC: 0 0 ES: 0 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Previous 1 day time = 24 hours 0 sec FEC: 16951 261218 CRC: 5 0 ES: 2 0 SES: 0 0 UAS: 0 0 LOS: 0 0 LOF: 0 0 LOM: 0 0 Total time = 1 days 4 hours 27 min 2 sec FEC: 23737504 11109799 CRC: 101581 1 ES: 1846 1160 SES: 627 0 UAS: 249 43409 LOS: 10 1104 LOF: 74 1104 LOM: 0 0 ============================================================================