Hallo, vielen Dank für die Info! Über die Updatefunktion habe ich jetzt auch die RC2! Gruß Horst

Firewall –> Virtual IPs Anschliessend NAT Regeln erzeugen die die zuvor erstellten VIPs verwenden.

# Die ermittelte mtu für das tun Interface. # Wir fügen die Optionen fragment und # mssfix hinzu, um ein Aushandeln der # Paketgroessen zu ermoeglichen tun-mtu 1492 fragment 1300 mssfix was "fragment" und "mssfix" bedeutet, weiss ich nicht, aber diese zeilen findet man, wnen man in google nach "tun-mtu openvpn" sucht. Hoffe das hilft, ich selbst, muss diese Anpassungen trotz T-Online private and Business nicht anpassen.

ich weiss nicht, wie man die ACLs aufbauen muss, aber probiere es doch mal mit: -i .(exe) oder die ausführliche variante: .(exe|exE|eXe|Exe|eXe|eXE|ExE|EXe|EXE) Gruß

Ich meine der hat noch irgendein Problem auf der Pfsense direkt. Dazu mein Tracert von der Pfsense gui nach google.de Traceroute output: 1  10.100.100.1 (10.100.100.1)  0.820 ms  0.569 ms  0.404 ms 2  * * * 3  1230.koeln.unity-media.net (1.2.3.4)  6.136 ms  4.846 ms  5.938 ms 4  216.239.48.11 (216.239.48.11)  16.437 ms  16.956 ms  23.998 ms usw Das kann doch nicht normal sein mit den Sternchen oder?

Nachtrag … hier steht das mit dem DHCP und der Bridge: http://forum.pfsense.org/index.php/topic,33878.msg175878.html#msg175878 Bin mir nicht sicher, ob man das nur braucht, wenn nicht pfSense der DHCP Server ist. Muss man halt ausprobieren! Da die System Tuneables geändert wurden, wird auch nur die 1. Regel pro physikalischem Interface benötigt (Pass UDP from 0.0.0.0:68 to 255.255.255.255:67 Allow DHCP) und nicht die zweite, wie im Post suggeriert wird. So kannst du alle restlichen Regeln ausschließlich auf dem logischem LAN Interface konfigurieren und musst dies nicht für jeden einzelnen physikalischem Port machen ...

Ich hab hier zufällig ne Anleitung gefunden: Festedrücken statt pkg_add -r -v ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/All/lcdproc-0.5.2_2.tbz nimmst du pkg_add -r -v ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/lcdproc-0.5.4.tbz und statt pkg_add -r -v ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/All/autoconf-2.62.tbz nimmst du pkg_add -r -v ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/autoconf-2.68.tbz Den Rest nach Anleitung, kann eigentlich nix schief gehen. Das mit rc.conf kannst vergessen, die wird bei pfS wohl nicht abgefragt. Ich hänge selbst noch am Autostart und bekomm nur LCDd geladen, lcdproc will nicht  :P Gruß, Thorsten

Hi, also ich sehe, um ehrlich zu sein, keinen Fehler. Bei den PortForwardings könntest du als Destination Address schonmal "WAN Address" einstellen, denn das ist ja die IP, die du ansprichst und nicht "any". Ansonsten würde es meiner Ansicht nach reichen, wenn du sowohl bei der Firewall Regel als auch beim PortForwarding jeweils den Destination Port auf 182 umstellst. Jenachdem, was du bei der NAT rule einstellst, wird automatisch eine Firewall regel erstellt oder eben nicht. Wichtig ist, dass es eine gültige Firewall Regel auf der WAN Schnittstelle gibt.

gefixt! die Server 2008 Firewall war auch noch mitbeteiligt…. peinlich peinlich Trotzdem vielen Dank an den Frosch!

Servus, ich habe es nun nochmal mit IPSEC versucht und siehe da: Der Tunnel steht. Problem: Mir ist nicht ganz klar wie das funzt? ESP kann maximal auf der linken Seite zur pfS1 geleitet werden, auf der rechten Seite erlaubt das NAT nur die angebeben Ports. Der Tunnel läuft auch nur wenn links ESP verfügbar ist, die Gegenprobe habe ich schon gemacht. Auf beiden pfS ist NAT-T-Option im IPSEC aktiviert. Müsste nicht auf beiden Seiten ESP verfügbar sein? [image: IPSEC.jpg] [image: IPSEC.jpg_thumb]

Stimmt, da hätte ich ja auch drauf kommen können.  :) Danke dir.

Hi Tron, Die LAN Regel lässt alles durch, was nach TCP riecht. In den Firewalllogs kannst du per Klick auf das "Blocked" Symbol erkennen, welche Regel geblockt hat.

Hi Frosch, danke für die Info, auch wenn man das natürlich ungern hört  ::) Ich hatte es ja fast schon befürchtet dass das Glump nicht tut… Tja, warten und hoffen. Vielleicht bekomm ich ja wenigstens das LCD-Problem behoben  :-\ Gruß, Thorsten

Ich versteh das einfach nicht. Wir haben 2 A-DSL Leitungen (einmal Telekom und einmal Arcor). Eingerichtet nicht an der Pfsense über PPPOE sondern mit den jeweiligen Routern als GW. Die funktionieren problemlos so wie erwartet. Die S-DSL Leitung (von Arcor) mit mehreren festen IP's funktioniert "eigentlich" auch problemlos. Nur sobald ich der pfsense eine der festen IP's gebe und versuche darüber ins Netz zu gehen funktioniert eine ganze Menge nicht mehr. Surfen im Netz geht… Speedtest Download geht, upload nicht. Uploads per scp oder rsync gehen ebenfalls nicht... hat irgendjemand ne Idee?

Jetzt funktionierts, der Port 1723 darf nicht die Quelle sein sondern das Ziel dann gehts auch. Danke nochmal

Moin! Die Rules auf OpenVPN-IF sitzen beidseitig auf Pass * * * * * * *. Tracert lässt die Route an der WANIP der anderen pfS enden. Gruß. Thorsten

Hallo zusammen, ich habe die Antwort selbst gefunden. Es geht. Und es geht sowohl mit IPSec, als auch mit openVPN. Den für mich entscheidenden Hinweis in Kombination mit IPSec war dieser hier: – schnipp -- You need parallel tunnels for this to work. unfortunately routing across a tunnel doesn't work (yet). Example: LAN1-------pfSense1-----(Internet)---------pfSense2-----------LAN2-------ROUTER------LAN3 You have to use different identifiers at both ends for the tunnels as both tunnels are established between the same public IPs so the traffic of the tunnels doesn't mix up. At pfSense1: create one preshared key like identifier "" with secret "lan2" (this is for the "unrouted" tunnel) create one preshared key like identifier "" with secret "lan3" (this is for the "routing to next hop" tunnel) At pfSense2 create the same keys. Now create the tunnels: The first tunnel is simple as it is for the directly connected LAN-segments at both pfSenses (LAN1 and LAN2). Create it just like you usually would do but use the "" identifier and secret at both ends. The second tunnel works like this: At pfSense1 (only special settings mentioned that are different from the other tunnel): local subnet: lan subnet remote subnet: LAN3/subnetmask identifier and secret of "" At pfSense2: local subnet: LAN3/subnetmask <–-- !!! remote subnet: LAN1/subnetmaks identifier and secret of "" Additional to this you need a static route at pfSense2 pointing towards LAN3 via gateway ROUTER. (and of course you need a route at ROUTER pointing to LAN1 via pfSense2) – schnapp -- Ich habe es in virtuellen Maschinen nachgebaut und es funktioniert bestens. Bei openVPN war der entscheidende Hinweis dieser hier: -- schnipp -- Remote network: Enter the remote(Clients) LAN here, to access more than one network, use the custom options field. -- schnapp -- Und das ganze dann in dem Format: Additional local subnets should be added to the custom options like so  (x.x.x.x is the subnet start IP, y.y.y.y is the subnet mask):  push "route x.x.x.x y.y.y.y"; Gruß Christian