16.12.2016

5987

PfSense und openVPN Bridge mit einer Netzwerkkarte

gelöstFrage Netzwerke LAN, WAN, Wireless

Hallo,

ich möchte gerne ine Bridged VPN netzwerk aufbauen auf einem pfsense, was wiederum auf einem Virtuellen XenServer im Netz (192.168.1.0/24) läuft.

Ich habe nur eine Netzwerkarte an dieser VM, die IP ist: 192.168.1.10 (WAN)

Verbindung zu dem Server klappt einwandfrei, nur leider kann ich die Clients in dem netz nicht anpingen. Dachte mir, dass ich iwie den WAN Interface mit dem TAP Device bridgen kann, aber leider hab ich da nen Denkfehler iwie un das gesamte system ist dann nicht mehr zu erreichen. Ich lese immer dass man noch ein LAN interface erstellen sollte, aber ich bestze nur eine Netzwerkkarte, die an das Heimnetz angeschlossen ist.

Geht mein Vorhaben überhaupt, mit nur einer echten Netzwerkkarte?

Danke für eure Hilfe

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 324081

Url: https://administrator.de/forum/pfsense-und-openvpn-bridge-mit-einer-netzwerkkarte-324081.html

Ausgedruckt am: 29.04.2025 um 23:04 Uhr

28 Kommentare

Neuester Kommentar

Bridging im VPN ist generell keine gute Idee und man kann dir nur dringenst abraten ! Auch die OpenVPN Doku selber rät aus gutem Grund davon ab !
Gibt es einen triftigen Grund warum du Bridging machen musst ??
Wenn nein solltest du immer klassisches Routing vorziehen.

nur leider kann ich die Clients in dem netz nicht anpingen.

Dein Netzwerk Design ist etwas verwirrend und nicht schlüssig beschrieben.
Normal hängt man das interne Netz des Hypervisors wo alle VMs draufliegen mit einem vSwitch an den lokalen LAN Port der pfSense (sofern diese auch als VM rennt) und der WAN Port der pfSense wird im Hypervisor auf dessen physischen Ethernet Port (NIC) gebridged.
So sähe ein klassisches Standardszenario aus !
Zu dem Thema Firewall in einer VM muss man wohl nichts mehr sagen hier, aber du weisst sicher was du da tust.
Eine Netzwerkkarte ist generell kein Problem oder meinst du damit das du die pfSense nur einbeinig angeschlossen hast ??
Eine kleine Skizze wäre hilfreich.
Ansonsten sind alle deine ToDos hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
bzw. das Bridging:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...

hallo,

ich wollte ein bridged vpn nutzen um Broadcasts zu senden. Zb für wake on lan oder zb wenn ich andere protokolle nutzen möchte wie samba etc

Habe mal ein geroutetes VPn aufbauen wollen, verbindung usw klappt alles einwandfrei. Leider kann ich die ips im 192.168.1.0/24 Netz auch nicht anpingen.

Hier mal der config des Routed Servers, da ich es überhaupt erdsma nur zum laufen bekommen möchte (Die software fw in pfsense hab ich bereits soweit aufgebohrt):

dev ovpns2
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 192.168.1.10 <--- IP DER PFSENSE MASCHINE
tls-server
server 10.16.16.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server2
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server2" via-env  
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'CERT_SRV' 1"  
lport 1234
management /var/etc/openvpn/server2.sock unix
max-clients 3
push "route 192.168.1.0 255.255.255.0"  
push "dhcp-option DNS 192.168.1.193"  
client-to-client
duplicate-cn
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server2.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float
topology subnet

Zb für wake on lan oder zb wenn ich andere protokolle nutzen möchte wie samba etc

Das ist Unsinn für Samba braucht man kein Broadcastsing das ist routebar !
Genau diese Broadcasts belasten dir den Tunnel und seine Performance. Überlege dir das also gut.
Ansonsten ist die Routed Konfig soweit OK.

Für alle Clients auf die du zugreifen willst die die pfSense NICHT als default Gateway haben musst du zwingend eine statische Route auf das interne OVPN Netzwerk 10.16.16.0 /24 eintragen. Vergiss das nicht.
Dieser Thread beschreibt das:
Server in Subnetz über VPN Router erreichen

Ich dacht eigentlich, das dies durch den eintrag push "route 192.168.1.0 255.255.255.0" geschieht?

Weil , das setzen einer statischen Route auf die ganzen Clients finde ich doch ein wenig umständlich, es handelt sich um bis zu 100 an der zahl

Ein WOL Rundruf auf die Clients im Netz ist auch mit Routing möglich?

Nicht denken sondern nachdenken !! Bzw. mal das Tutorial hier lesen !
Das Push Kommando injiziert beim Tunnelsession Aufbau das lokale LAN Netz am Server in die Client Routing Tabelle, damit der das Netzwerk auch findet und weiss das er das in den Tunnel routen muss und nicht zum Provider !
Ein route print bei Winblows Clients zeigt dir das auch bei aktivem Tunnel !

statischen Route auf die ganzen Clients finde ich doch ein wenig umständlich

Macht ja auch kein normaler Mensch bzw. Netzwerker....!
Du hast auch den Thread nicht richtg gelesen !! Es geht um das interne Netz des VPNs !!!
Das können Endgeräte die aus dem VPN angesprochen werden und ein anderes Gateway haben logischerweise nicht kennen.
Steht ja auch alles in der Erklärung zum zitierten Thread...wenn man den denn mal liest

Ein WOL Rundruf auf die Clients im Netz ist auch mit Routing möglich?

Bedingt...
https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html
Die pfSense hat aber auch eine Option um WoL Paket lokal zu senden ! Doku lesen !
https://doc.pfsense.org/index.php/Wake_on_LAN

Ok danke ich hab es mal versucht einw neig auf meine Situation zu adaptieren, habe aber anscheinend ein kleines Verständnisproblem noch:

ich versuche es nochmal ein wneig zu schildern, wie es intern aussieht bei mir:

ISP -- Fritzbox Router (192.168.1.1) --- (Clients,Server etc und unter anderem der Pfsense Server mit der ip 192.168.1.10)

Pfsense hat ein Interface mit der IP 192.168.1.10 und dort wiederum ist das GW der fritze eingetragen also 192.168.1.1
Routen auf dem Pfsense Server habe ich nicht eingetragen

Habe nun in die Fritzboxbox unter Routing eine Route eingetragen:

Ziel: 10.16.16.0 | 255.255.255.0 | GW: 192.168.1.10
Bei deinem Link im Beispiel war ich mir nicht sicher, ob dort eine zweite Route notwendig ist?

Von einem anderen standort (internes netz 192.168.22.0/24 GW: 192.168.22.1) möchte ich gern darauf dann per vpn zugreifen.

Pfsense hat ein Interface mit der IP 192.168.1.10

LAN oder WAN Port der pfSense ??

Von einem anderen standort (internes netz 192.168.22.0/24 GW: 192.168.22.1) möchte ich gern darauf dann per vpn zugreifen.

Das ist ja kein Problem wenn OVPN richtig eingerichtet ist. Ein simpler Standard.
Probelatisch ist hier eher die (sorry) dümmliche Wahl der 192.168.1.0er netzwerk Adresse für das lokale LAN.
Siehe dazu auch hier:
VPNs einrichten mit PPTP

Das Interface ist ein WAN, hat allerdings auf dem dashboard ein icon das normalerweise für die LAN interfaces gebnutzt wird.

Nunja, das eintragen der routen hat nichts gebracht, bzw ich habs wohl komplett falsch gemacht un es muss in die pfsense maschine eingetragen werden?

Zur wahl mit dem 192.168.1.0er netz: ja ich weiss auch. Es wurd etwas unglücklich gewählt, sollte aber in dem fall nicht schlimm sen, da alle user die connecten wollen ein anders subnetz jeweil zuhause haben.

hat allerdings auf dem dashboard ein icon das normalerweise für die LAN interfaces gebnutzt wird.

Das kann nicht sein und zeigt eher das das eben KEIN WAN Port ist sondern du es falsch konfiguriert hast.
Letztlich aber egal, denn ob du per WAN oder LAN zugreifst spielt keine Rolle.
Beim WAN Port sind halt die FW Hürden erheblich größer, da dieser Port natürlich durch entsprechende Regeln logischerweise gesichert ist, ist ja der Internet Port.
In einer Kaskade müsste hier der Haken bei Block RFC 1918 networks entfernt werden und im Regelwerk zuerst als erste Regel der Zugriff von UDP 1194 (OVPN Default Port) auf die Interface IP erlaubt werden.

Nunja, das eintragen der routen hat nichts gebracht, bzw ich habs wohl komplett falsch gemacht

Hast du vermutlich !! Nur so ist das zu erklären, denn das ist ein simples Standard design.
Die Routen müssen natürlich auf dem Internet Router eingetragen werden, sprich also dem Gerät was die Endgeräte als default Gateway eingetragen haben !!
Siehe HIER !
Auf der pfSense muss nur ein Default Gateway eingetragen werden.
Das Traceroute Kommando (tracert) oder pathping sind hier deine Helfer zum Troubleshooting. Da wo es kneift ist auch der Fehler.
Sinnvoll zum Checken:

Wird der VPN Tunnel fehlerfrei aufgebaut ?? Hier mal Log vom VPN Client und von der pfSense posten
Mit route print auf dem Client bei aktivem Tunnel mal checken ob die Routing Tabelle korrekt ist
Traceroute und Ping Test zum Endgerät

Also um nochma auf den WAN/LAN Port zurückzukommen, habe ich bei den Regeln einfach alles erlaubt, sollte daher "eigentlich" nichts mehr im wege stehen.

Zu dem Log vom VPN Client:

Sat Dec 17 19:54:10 2016 OpenVPN 2.3.11 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Sat Dec 17 19:54:10 2016 Windows version 5.1 (Windows XP) 32bit
Sat Dec 17 19:54:10 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.09
Enter Management Password:
Sat Dec 17 19:54:26 2016 UDPv4 link local (bound): [undef]
Sat Dec 17 19:54:26 2016 UDPv4 link remote: [AF_INET]80.xxx.xxx:1234
Sat Dec 17 19:54:26 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Dec 17 19:54:26 2016 [AIF_CERT_SRV] Peer Connection Initiated with [AF_INET]80.xxx.xxx:1234
Sat Dec 17 19:54:28 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Dec 17 19:54:28 2016 open_tun, tt->ipv6=0
Sat Dec 17 19:54:28 2016 TAP-WIN32 device [openVPN-TAP DEVICE] opened: \\.\Global\{54F7199F-3F10-4C68-A56D-E3B595E16ADF}.tap
Sat Dec 17 19:54:28 2016 Set TAP-Windows TUN subnet mode network/local/netmask = 10.16.16.0/10.16.16.3/255.255.255.0 [SUCCEEDED]
Sat Dec 17 19:54:28 2016 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.16.16.3/255.255.255.0 on interface {54F7199F-3F10-4C68-A56D-E3B595E16ADF} [DHCP-serv: 10.16.16.254, lease-time: 31536000]
Sat Dec 17 19:54:28 2016 Successful ARP Flush on interface [65541] {54F7199F-3F10-4C68-A56D-E3B595E16ADF}
Sat Dec 17 19:54:34 2016 Initialization Sequence Completed
Sat Dec 17 19:54:34 2016 Start net commands...
Sat Dec 17 19:54:34 2016 C:\WINDOWS\system32\net.exe stop dnscache
Sat Dec 17 19:54:34 2016 C:\WINDOWS\system32\net.exe start dnscache
Sat Dec 17 19:54:36 2016 C:\WINDOWS\system32\ipconfig.exe /flushdns
Sat Dec 17 19:54:37 2016 C:\WINDOWS\system32\ipconfig.exe /registerdns
Sat Dec 17 19:54:37 2016 End net commands...

Auf den VPN Server komme ich atm leide rnicht drauf kann den log da gern mal nachreichen

routing tabelle client:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.22.1   192.168.22.23       25
       10.16.16.0    255.255.255.0       10.16.16.3      10.16.16.3       30
       10.16.16.3  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255       10.16.16.3      10.16.16.3       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.1.0    255.255.255.0       10.16.16.1      10.16.16.3       1
     192.168.22.0    255.255.255.0    192.168.22.23   192.168.22.23       25
    192.168.22.23  255.255.255.255        127.0.0.1       127.0.0.1       25
   192.168.22.255  255.255.255.255    192.168.22.23   192.168.22.23       25
        224.0.0.0        240.0.0.0       10.16.16.3      10.16.16.3       30
        224.0.0.0        240.0.0.0    192.168.22.23   192.168.22.23       25
  255.255.255.255  255.255.255.255       10.16.16.3           10003       1
  255.255.255.255  255.255.255.255       10.16.16.3      10.16.16.3       1
  255.255.255.255  255.255.255.255    192.168.22.23   192.168.22.23       1
Default Gateway:      192.168.22.1
===========================================================================
Persistent Routes:
  None

pathping hat folgendes ergeben:

#> pathping 192.168.1.10

Tracing route to localhost [192.168.1.10]
over a maximum of 30 hops:
  0  CLIENT_VPN [10.16.16.3]
  1     *        *        *
Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           CLIENT_VPN [10.16.16.3]
                              100/ 100 =100%   |
  1  ---     100/ 100 =100%     0/ 100 =  0%  CLIENT_VPN [0.0.0.0]

Trace complete.

#> pathping 10.16.16.254

Tracing route to localhost [10.16.16.254]
over a maximum of 30 hops:
  0  CLIENT_VPN [10.16.16.3]
  1     *        *        *
Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           CLIENT_VPN [10.16.16.3]
                              100/ 100 =100%   |
  1  ---     100/ 100 =100%     0/ 100 =  0%  CLIENT_VPN [0.0.0.0]

Trace complete.

#> pathping 10.16.16.1

Tracing route to localhost [10.16.16.1]
over a maximum of 30 hops:
  0  CLIENT_VPN [10.16.16.3]
  1     *        *        *
Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           CLIENT_VPN [10.16.16.3]
                              100/ 100 =100%   |
  1  ---     100/ 100 =100%     0/ 100 =  0%  CLIENT_VPN [0.0.0.0]

Trace complete.

Sieht gut aus ! Tunnel und Client melden das der VPN Tunnel korrekt aufgebaut ist. Da stimmt alles.
Das ist jetz nur noch Routing oder Firewall oder beides in Kombination.

Das Gerät .1.10 was du anpingst ist das ein Winblows Rechner ??

Bedenke das dort in der lokalen Windows Firewall ab Win7 und höher ICMP (Ping und Traceroute) per Default geblockt wird !!
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Das musst du erst freigeben.

Falls dieser angepingte Rechner ein anderes Default Gateway hat als der OpenVPN Server MUSST du auf dem Gateway eine statische Route auf das interne VPN IP Netz 10.16.16.0 /24 eintragen mit next Hop auf den VPN Server !!
Entsprechend natürlich auch eine Firewall Regel für dieses Netz wenn du nicht eine any to any Regel definiert hast ?!

Der 1.10er ist der pfsense server der als default gw 192.168.1.1 (Die Fritzbox) eingetragen hat. habe den einfach nal bispielsweise genommen, aber selbes ergebnis kam aus jedem client im 192.168.1.0/24 Netz, die clients haben hier alle als GW die 192.168.1.1 eingetragen.

FW ist auf dem Client System aufgeschaltet.

Also kurz zur übersicht:

192.168.1.0/24 Firmen-Netz:
- PFsense mit VPNserver: Interface 192.168.1.10 mit GW 192.168.1.1
(Sonst kein Interface hier verfügbar/definiert + alle FW Rules auf any to any)

- FB 192.168.1.1 mit statischen routen:
Ziel: 10.16.16.0 | 255.255.255.0 | GW: 192.168.1.10
Ziel: 192.168.22.0 | 255.255.255.0 | GW: 192.168.1.10

192.168.22.0/24 Heimnetz
Windows Client: 192.168.22.23 (FW deaktiviert)
GW /Router 192.168.22.1

Hallo, nach einigem hin un her un neustarts der fritze hab ich es nun doch zum laufen bekommen mit obiger config, vielen dank hierfür! (inkl. des kleinen exkurs ins routing)
Auch das DNS des Ad-Servers wird korrekt eingetragen.

eine kleine sache allerdings nervt mich hier noch:

1. Samba (Protokoll) Freigaben kann ich werder per \\DNSfreigabe noch per \\IP aufrufen, den NAS Server allerdings kann ich aufrufen.

2. Wir haben ein Intranet CMS System auf einem Debian server. Die Website lädt un lädt, auch ein connecten per SSH auf diesen Linux server möchte einfach nicht gelingen, im syslog und access steht nichts... wie gehe ich am besten an die sache dran?

3. LZO komprimierung empfehlenwert, für speedup oder eher nicht?

1.)
Da schlägt dann deine lokale Firewall vermutlich zu. Die musst du anpassen das SMB Anfragen von der entsprechenden Absender IP durchgehen..
2.)
Mit Sicherheit gleiche Problematik wie 1.)
3.)
Ja. sollte man immer aktivieren.

OK, das mit den SMB anfragen läuft jetzt soweit, lag aber nicht an der FW die war deaktiviert.. war wohl iwas anderes nunja....

Das mit dem Intraweb apache server is immenroch komisch.. die iptables habe ich mal geflushed.

root@srv_1:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

es wird auch teils ein aufbau der website angesetzt allerdings unterirdisch langsamer aufbau (unterhalb eines 56k modems) dabei ist es lediglich ein bisschen html und das mit dem ssh klappt leider auch garnicht. dabei habe ich in der sshd_conf den ListenAdress auf ::: und 0.0.0.0 gesetzt um alles anzunehmen. :\ Teilweise wird mir manchmal auch das eintippen des benutzers zumindest angeboten, doch anch dem passwort eintippen, bekomm ich enn connection lost problem.

Scheint als gäbe es iwo an der stelle ein PacketLost, wie kann ich hier das Problem am besten angehen? :\

Das hört sich dann nach einem MTU Problem auf der VPN Vertbindung an !! Hast du die entsprechend angepasst ??
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Also...zwingend die Tunnel MTU anpassen !

tun-mtu hab ich auf server sowie auf client auf 1400 gesetzt, leider das selbe spiel.. auch mit anderen werten

weiterhin packet loss oder abbrüche. Kann es evtl an dem debian server liegen? mtu einstellung im linux kernel oder ähnliches?

Interessant ist: eine VPN verbindung mit IPSec (die ich mal beispiehaft erstellt habe, aber ungern nutzen möchte) über die fritzbox hat nicht solche probleme. auch wenn es allgemein ein klein wenig langsamer ist.

Interessant ist zu dem auch: ich komme wenn ich meine openvpn verbindung offen habe ohne weitere probleme un verbindungsabbrüche auf das Webinterface oder SSH des pfsense servers!

Bin ein wenig mit dem latein am ende

Sinnvoll wäre mal einen Durchsatztest zu machen mit NetIO was so durch den Tunnel geht und wie der sich unter Belastung verhält:
http://www.ars.de/ars/ars.nsf/docs/netio
http://www.nwlab.net/art/netio/netio.html
Einmal mit TCP und einmal mit UDP Frames.

hallo, danke, habe nun an den messungen einen schwellenwert ermitteln können den ich mit einem : ping -l 1372 192.168.199 festlegen konnte auf die magische zahl von 1372 Bytes? aber warum? wo ist der engpass? warum nicht die gewohnten 1500 Bytes die doch eig openVPN als standard setzt?

Das Thema MTU sagt dir was ?? Scheinbar wohl nicht wie deine Fragestellung leider vermuten lässt.
PPPoE Encapsulierung und UDP VPN Encapsulierung nagen an der 1500 Byte Paketsize. Die Netto Size muss also weitaus kleiner sein das mit dem Overlay nicht die 1500er Größe gesprengt wird und der Router fragmentieren müsste.
Lies dir bitte das Wiki zum Thema MTU und MSS durch ! Oder hier findest du auch eine Erklärung:
http://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...

Hallo ich meld mich mal nochma zurück, leider hab ich das problem immenroch nicht lösen können

habe nun in die vponserver konfig mehmals vershciedneen mtu werte eingetragen:

tun-mtu 1500;fragment 1400;mssfix usw.

Ohne erfolg.. Das interessante ist zudem das auf dem windows server keine probleme auftreten. der Apache serve rmacht leider zicken nach wie vor. Der MTU auf der Maschine liegt bei 1500, Sollte ich dort evtl etwas umstellen können?

Nein, beim Endgerät musst du da nix machen. Geräte machen vorher auf dem L2 Pfad eine max. MTU Negotiation.
Du solltest testweise nochmal den MTU Wert im Tunnel auf unter 1400 Byte verkliener und ihn testweise mal auf 1300 setzen.

Auch ein wert von 1300, 1260 etc brachte keinen erfolg.. wenn ich manchmal glück habe lädt er eine seite des apche nach ca einer minute aber das wars dan meistens auch schon.

ein anderer linux pc im netz der einen kleineren webserver hat, zeigt genau das selbe problem.

Ich habe nun auf einem windows server einen xampp mal testweise laufen lassen, da gehts wiederum ohne probleme... mtu bei 1500, also standardconfig.
die server/rechner liegen alle im selben netz auf einem Xenserver
Auch so sachen wie Remote Desktop laufen super schnell un zuverlässlich

Ich kann mir leider nicht ausmalen, ob es nun ein generelles problem mit linux gibt, wobei ich so sachen wie firewall etc ja auch nicht laufen haben?

Möglich das die MTU Path Negotiation bei deiner Linux Distro deaktiviert ist oder sowas. Das müsste man mal mit einem Wireshark Trace ansehen.
Wenn bei gleicher Konstellation mit dem XAMP rennt dann ist auch nicht die MTU das Problem...oder nur zweitrangig.
Wie gesagt, da hilft dann nur ein genauer Trace des Packet Flows um das rauszubekommen.
Klingt aber schon etwas ungewöhnlich.
Kannst du nochmal einen HTTP Server ohne Konfig und Install austesten wie den HFS Webserver:
http://www.rejetto.com/hfs/
Der rennt direkt von einem Stick etc.
Verhält der sich auch so oder rennt das damit ?

Hallo, habe nochmal ein paar nachforschungen angestellt.

1. hfs hab ich nicht direkt getestet, allerdings vershciedenne andere webserver. lidghttpd nginx (light) bei allen das bekannte problem, auch auf verschiedenen ports.

2. habe afi meinem windows rechner mal eine vm aufgemacht mit debian un apache. dies dann per vpn aufgerufen, und es klappt. also kann man schon fast davon ausgehen das es nicht an linux liegt?

3. der webserver liegt auf einem Xenserver. Dort habe ich zudem mal mit einem Livesystem versucht zu booten un apache rennen lassen. Das selbe problem auch hier mit dem packetverlust :\

4. weiss leider nur bedingt, welche pakete ich nun tracen sollte . habe es mal mit google recherche versucht: (.30 ist die VM auf der openVPN und pfsense läuft | .60 ist dann der webserver)

root@server:~# tcpdump -s0 -p -ni eth0 '(ip and ip[20+13] & tcp-syn != 0)' 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
37:14.168264 IP 192.168.1.30 > 192.168.1.60: ICMP echo request, id 45616, seq 128, length 40
37:14.168292 IP 192.168.1.60 > 192.168.1.30: ICMP echo reply, id 45616, seq 128, length 40
37:14.571233 IP 192.168.1.163.5353 > 224.0.0.251.5353: 0 [2q] PTR (QM)? _0F9D5165._sub._googlecast._tcp.local. PTR (QM)? _googlecast._tcp.local. (61)
37:15.168763 IP 192.168.1.30 > 192.168.1.60: ICMP echo request, id 45616, seq 129, length 40
37:15.168792 IP 192.168.1.60 > 192.168.1.30: ICMP echo reply, id 45616, seq 129, length 40
37:16.168538 IP 192.168.1.30 > 192.168.1.60: ICMP echo request, id 45616, seq 130, length 40
37:16.168567 IP 192.168.1.60 > 192.168.1.30: ICMP echo reply, id 45616, seq 130, length 40
37:33.752143 IP 192.168.1.30.53348 > 192.168.1.60.80: Flags [S], seq 610622853, win 8192, options [mss 1352,nop,nop,sackOK], length 0
37:33.752193 IP 192.168.1.60.80 > 192.168.1.30.53348: Flags [S.], seq 627372028, ack 610622854, win 29200, options [mss 1460,nop,nop,sackOK], length 0

zudem gab es noch die option diese kernelparameter zu setzen, löst nicht das problem, denke mal da ist auch der falsche ansatzpunkt?:

echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing
echo 1024 > /proc/sys/net/ipv4/tcp_base_mss

Ich hab sonst leider keine lösung gefunden, wo ich die mtu path negotiation in linux ändern kann? könntest du das evtl noch ein wneig näher erläutern?

PS: Es gab zudem auch probleme mit den freigaben auf dem Fileserver (Windows 2003 Server) dort ist leider auch kein zugriff möglich im VPN tunnel

So hier mal ein wireshark trace des VPN Clients:

https://www.cloudshark.org/captures/d1

und hier nochmal ein trace mit gesetztem mtu 1350 auf dem Interface sowei im clientconfig "fragment 1350 ; mssfix"

https://www.cloudshark.org/captures/da

10.16.16.0/24 sind die clients : 192.168.1.199 ist der test-webserver

Hallo,
ich konnte das Problem endlich nach langem Haareraufen und Recherchen lösen:

Es lag direkt an xenserver, da mir die oben beschriebenen Probleme schon komisch vorkamen.
Lösung brachte ein deaktivieren der offload einstellungen in der vm in der pfsense/openvpn läuft

Wen es interessiert, hier die settings, im xenpool:

#vif ID finden mit xe vif-list vm-uuid={pfsense vm}
xe vif-param-get uuid={uuid vif} param-name=other-config
xe vif-param-set uuid={uuid vif} other-config:ethtool-tx="off"  