<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Internet Übertragungsprobleme über VPN Tunnel]]></title><description><![CDATA[<p dir="auto">Hallo an alle hier im Forum,</p>
<p dir="auto">ich habe 2 PFsensen mittels routed IPSEC VPN verbunden. Die Verbindung funktioniert einwandfrei ohne jegliche Probleme.</p>
<p dir="auto">Jetzt wollte ich das ein PC an Standort A über das Internet vom Standort B ins Netz kommt. Dazu habe ich in den Firewall Regeln eine Regel mit dem VPN Interface als Gateway erstellt und aktiviert.</p>
<p dir="auto">Allerdings habe ich das Problem das das Surfen leider nicht sauber funktioniert. ein Ping und auch die DNS Auflösung funktionieren einwandfrei und wenn ich ein tracert mache geht die Anfrage auch über die Pfsense an Standort B raus. Allerdings bauen sich die Seiten nicht auf, oder aber die eine oder andere Seite öffnet sich ein wenig und lädt dann nicht fertig. Habe ich noch etwas besonderes übersehen was ich noch einstellen muss?</p>
<p dir="auto">Vielen Dank schon mal für eure Tipps</p>
<p dir="auto">Grüße<br />
Marco</p>
]]></description><link>https://forum.netgate.com/topic/166893/internet-übertragungsprobleme-über-vpn-tunnel</link><generator>RSS for Node</generator><lastBuildDate>Sat, 13 Jun 2026 06:12:15 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/166893.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 30 Sep 2021 18:08:03 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Internet Übertragungsprobleme über VPN Tunnel on Fri, 01 Oct 2021 11:51:49 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/viragomann">@<bdi>viragomann</bdi></a> Darum meinte ich auch, es könnte das oder die NAT Problematik sein:</p>
<blockquote>
<p dir="auto">There are also known issues with NAT, notably that NAT to the interface address works but 1:1 NAT or NAT to an alternate address does not work.</p>
</blockquote>
<p dir="auto">Da ich nicht weiß/sehen kann, wie <a class="plugin-mentions-user plugin-mentions-a" href="/user/zickzack2021">@<bdi>zickzack2021</bdi></a> die sensen auf beiden Seiten konfiguriert hat und was da an NAT, CARP oder sonstwas dran hängt, bin ich da auch im Blindflug, wenngleich ich dir recht gebe, dass sich das im Prinzip schon eher nach asym. Routing anhört. Aber auch da müssen wir ja raten, weil wir nicht wissen, wie Standort A/B ins Internet angebunden sind und ob die Sensen auch das Default GW im Netz sind. :)</p>
]]></description><link>https://forum.netgate.com/post/1003955</link><guid isPermaLink="true">https://forum.netgate.com/post/1003955</guid><dc:creator><![CDATA[JeGr]]></dc:creator><pubDate>Fri, 01 Oct 2021 11:51:49 GMT</pubDate></item><item><title><![CDATA[Reply to Internet Übertragungsprobleme über VPN Tunnel on Fri, 01 Oct 2021 10:21:38 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/jegr">@<bdi>jegr</bdi></a><br />
Nein, reply-to kommt hier nicht zum Tragen.<br />
Die Quell-IP des über die VPN gerouteten und dann ins Internet raus gehenden Pakets ist eine interne, für welche ein Route im Remote-System bestehen muss. Ansonsten würde die interne Kommunikation zwischen den beiden Seiten ebenso nicht funktionieren. reply-to ist dafür gedacht, Reply-Pakete zu einer Public-IP wieder zum richtigen Gateway zurück zu routen (für den Fall, dass der Request nicht über das Default Gateway reinkommt).</p>
<p dir="auto">Das Problem hier klingt doch nach einem asymmetrischen Routing, doch ich kann mir nicht erklären, wie das hier zustande kommen sollte.</p>
]]></description><link>https://forum.netgate.com/post/1003943</link><guid isPermaLink="true">https://forum.netgate.com/post/1003943</guid><dc:creator><![CDATA[viragomann]]></dc:creator><pubDate>Fri, 01 Oct 2021 10:21:38 GMT</pubDate></item><item><title><![CDATA[Reply to Internet Übertragungsprobleme über VPN Tunnel on Fri, 01 Oct 2021 11:50:10 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/zickzack2021">@<bdi>zickzack2021</bdi></a> Ich bin mir gerade unschlüssig aber das könnte bedingt sein durch das (noch vorhandene) Fehlen des reply-to Tags bei VTI Tunneln.  Ich vermute mal das Problem spielt hier hinein:</p>
<p dir="auto"><a href="https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routed-vti.html#caveats" target="_blank" rel="noopener noreferrer nofollow ugc">https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routed-vti.html#caveats</a></p>
<blockquote>
<p dir="auto">Firewall rule processing can be confusing, as mentioned in Routed IPsec Firewall Rules. This is still undergoing testing, but likely means that reply-to will not function. There are also known issues with NAT, notably that NAT to the interface address works but 1:1 NAT or NAT to an alternate address does not work.</p>
</blockquote>
<p dir="auto">Reply-to funktioniert wohl bei VTI Tunneln noch nicht und auch bei NAT gibt es Limitationen und Probleme. Daher kommt dein Problem sehr wahrscheinlich daher, dass beim Rausgehen über den Tunnel und die andere Leitung dann outbound geNATtet wird und dabei dann ggf. die reply-to und NAT Probleme zum Tragen kommen und es problematisch machen.</p>
<p dir="auto">Es könnte natürlich auch noch was anderes sein, aber ohne detailliertere Infos zu Regeln, NAT und Routen ist das schwer zu sagen.</p>
<p dir="auto">Was sich einfach machen lassen sollte wäre den Tunnel  durch einen OpenVPN Tunnel zu ersetzen und nachzusehen, ob der Case dann funktioniert (was er sollte, da es ein simples Szenario für OVPN ist). Funktioniert es mit der annähernd gleichen Konfiguration mit OVPN wird es wahrscheinlich das Problem von VTI sein.</p>
<p dir="auto">Cheers</p>
]]></description><link>https://forum.netgate.com/post/1003934</link><guid isPermaLink="true">https://forum.netgate.com/post/1003934</guid><dc:creator><![CDATA[JeGr]]></dc:creator><pubDate>Fri, 01 Oct 2021 11:50:10 GMT</pubDate></item></channel></rss>