<?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[tunnel ipsec attivo ma ping non funzionante se non esplicitando il source ip]]></title><description><![CDATA[<p dir="auto">Ho un tunnel ipsec attivo con una controparte.<br />
Ci è stata assegnata la sottorete 10.68.245.199/29 per avere accesso alla loro 10.68.245.200/29</p>
<p dir="auto">Il mio povero pfSense ha un indirizzo pubblico, ovviamente, e due schede di rete che sono già "attaccate" a 2 diverse lan aziendali</p>
<p dir="auto">Lo scopo finale è che dalla nostra lan e da pfsense dobbiamo poter chiamare due ip della controparte</p>
<ul>
<li>10.68.245.201</li>
<li>10.68.245.202</li>
</ul>
<p dir="auto">Attualmente da pfsense riesco a pingare <em>esplicitando</em> l'uso del virtual ip 10.68.245.193 (uno di quelli della sottorete assegnataci), ma non so come fare perchè questa cosa avvenga autoamaticamente.</p>
<p dir="auto">se faccio un curl, per esempio, dalla shell, dall'host di pfsense, verso 10.68.245.201 o .202, non ottengo risposta.</p>
<p dir="auto">Ho provato a dare un virtual ip al localhost e alla wan, ma comunque facendo un curl dalla shell non ottengo risposta.<br />
Il ping, come dicevo, da Pfsense al 201 va solo se esplicito l'ip sorgente, per esempio usando il .193</p>
<p dir="auto"><strong>Come si fa a dire a pfsense che qualsiasi traffico diretto verso 10.68.245.200/29 deve essere veicolato tramite ipsec E SOPRATTUTTTO deve presentarsi alla controparte con un indirizzo della sottorete 10.68.245.192/92 ?</strong></p>
]]></description><link>https://forum.netgate.com/topic/179792/tunnel-ipsec-attivo-ma-ping-non-funzionante-se-non-esplicitando-il-source-ip</link><generator>RSS for Node</generator><lastBuildDate>Tue, 13 Oct 2026 03:23:22 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/179792.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 29 Apr 2023 15:42:44 GMT</pubDate><ttl>60</ttl></channel></rss>