@viragomann said in Outbound NAT over IPSEC tunnel not working: @shaunmccloud said in Outbound NAT over IPSEC tunnel not working: And the minute I add a P2 entry in my pfSense box for a remote network of 0.0.0.0/0, all network traffic but local dies. So I'd assume, that the traffic is routed over the VPN, but not out on WAN. But this is only the half of the battle. The traffic must be natted on the remote site If the Meraki doesn't masquerade your subnets there is no way to go out to the internet through it. I decided to cheat, and throw a virtual pfSense box in the data center to connect to. I'll see how that works tomorrow.

Just for information to everyone, the problem was solved by changing (on both sides, of course) from IKE v1 to IKE v2.

@Gblenn Just tested it with /31 and it works. For route-based IPsec the gateway is created automatically when you assign the tunnel to an interface. I haven't tried with /32 tho. But I tried with larger subnet like /24. I guess it's like what you said, as long as they are on the same subnet it will work. Just that for point-to-point connection with a single transit network it doesn't make sense to use something larger that contains more than 2 IPs.

@viragomann It’s a Cisco Meraki the router Site A! But, i’m thinking now: The traffic should be routed to 192.168.100.222, not for the gateway 192.168.100.1 (this is the router with the VPN tunnel). In the 100.1 router have static routes for route the traffic specified throught the 100.222 Is it the same solution (change phase 2 to 0.0.0.0/24)??? Thanks again

can you share P2 subnet/IPs of both end, and firewall rule configured on IPSec interface - both ends,

@viragomann said in Störung IPSec Aufbau nach Interntdowntime: Eine Erklärung für das Nicht-Upgraden ist hier praktisch obligatorisch. Anderenfalls drohen schlaue Weisungen oder gar ein regelrechter Shit-Storm. Antworten naja der Sturm nicht ;) aber da 2.7 und 2.7.2 schon etliche Updates gerade bei IPsec gemacht haben, würde es sich natürlich SEHR anbieten, erstmal auf den aktuellen Stand zu kommen. @hnoack85 said in Störung IPSec Aufbau nach Interntdowntime: etzt gab es am zweiten Standort einen kurzen Internetausfall, jedoch konnte die IPSec Verbindung nach Wiederherstellung der Internetverbindung nicht mehr automatisch aufgebaut werden. Erst nachdem ich den IPSec Dienst am zweiten Standort manuell neu gestartet habe, wurde die Verbindung wieder hergestellt. Aus dem IPSec Log habe ich dazu folgenendes heraus gelesen: Das hört sich sehr danach an, als könnte zwar Seite A mit B aber B nicht mit A die Verbindung aufbauen, was u.a. an NAT wie @viragomann geschrieben hat liegen kann. Ich würde da empfehlen auf beiden Seiten mal in der P1 den Verbindungsaufbau zu disablen (reply only) damit keine der beiden Seiten die Verbindung aufbaut. Dann manuell disconnecten. Dann auf Seite A versuchen aufzubauen und das ganze Spiel nach nochmals mit Seite B. Dann bekommt man schnell raus, ob es in beide Richtungen sauber läuft oder nicht, was ich hier denke nicht der Fall ist. Ansonsten ist der NO_PROP Error vielfältig, das liest sich im ersten Moment dann wie ein P1 oder P2 Encyption Fehler - also nicht exakt gleich eingestellte Phasen. Zusätzlich: wenn beide Seiten Sensen sind, dann nutzt da bitte auch AES-GCM-256 und nicht CBC wie es im proposal steht. Ich würde da beide Seiten fix auf AES-256-GCM, AES-XCBC (oder SHA-256) und DH20 stellen (ecp256 oder ecp384). Alles andere ist eigentlich unnötig überzogen. Ich weiß nie warum irgendwelche Hersteller da statt GCM sauber zu unterstützten immer noch mit "ja aber wir machen SHA512 und DH 21 mit ECP521!" - ja toll, aber das wichtige wäre GCM weils die CPU/Crypto entlastet und schneller ist und nicht irgendwelche Hashes oder Secrets die dann ultra doll verschlüsselt sind Cheers \jens

@stephenw10 Just wanted to follow up and mark this one as SOLVED — removing the <phase1>1</phase1> from <ipsec> fixed the PHP errors and allowed the interfaces to load. I’ve got it back in production and have a bit more work to restore to the original config, but your advice definitely made the difference! Thanks so much for the help.

@viragomann It is policy-based tunnel (Tunnel IPv4). Phase2 is working (status connected). Status->SystemLogs->IPSEc has no corresponding entries. But you said " and the subnet is not routed through the tunnel": This is exactly the problem - how to do this? As there are no thus options in the IPSec tunnel settings ("NAT/BINAT translation" should not be the corresponding option.)

@felipefonsecabh said in Access service in device connected via IPSEC trought public IP: I have change local network to Any to carry traffic from any external IP? Yes, if you are using policy based IPSec and need to keep using that. The policy has to match that traffic and the source IP could be any IP. But if you do that it will match traffic at the other end for 'any' destination. All traffic from site1 will go over the IPSec tunnel. Which you probably don't want. A route based VPN tunnel of some sort would give you more options.

@Topogigio the problem persists. After a few days pfSense stops binding the IP address on the established tunnel interface. I've started to build a new opnSense gateway, but if there is some pfSense solution I'll be happy

@felipefonsecabh said in Make a Túnnel trought IPSSEC and OpenVPN using PFSense: Router of External Access can ping DVC1 What source IP does it use for that? To pass the IPSec tunnel it must be in he 192.168.15.0/24 subnet. In which case it can only be the External Access router blocking traffic clients on it's LAN. Or potentially redirecting traffic past the IPSec tunnel? What is that device? Steve

@mebert Consider that you have to state the remote domain if you client uses another search domain, what I assume. So if you want to request the remote host name is "host" and its domain is "local" you need to type "host.local" to access it.

@timatleeTry turning the PFS key group on P2 to off and see what happens. I have a couple of IPSec connections with Fortigates, 1 with 4 SA's but that one has PFS key group set to off. Unless I am mistaken, by default, the DH for P2 inherits the DH from P1 unless specified differently. I also set my time lifetime 10% higher than the FortiGate, which seemed to help a lot.

Até agora, o que eu consegui: Fui em Firewall -> Virtual IPs -> IP Alias, e criei da seguinte forma: 172.25.16.1/24 Daí usei essa faixa como Phase2 da configuração do IPSec com a concessionária. Daí a concessionária consegue pingar normalmente 172.25.16.1, que é o PFSense. Daí criei um NAT 1:1 da seguinte forma: Interface: WAN External Subnet IP: 172.25.16.2 (endereço virtual do "Device" que é o dispositivo que quero enxergar) Internal IP: Any Destination: 192.168.102.10 NAT Reflection: Enable Porém a concessinária não recebe o ping desse endereço. Alguém tem ideia do que está faltando, ou como posso fazer esse redirecionamento?

@mclaborn Ok from there Id check the Routes table, I'd check all your firewall rules, and I'd run a tracert to see if if it going somewhere funky. Also check your Outbound NAT rules to see if there's a redirect there, too, or maybe you have a 1:1 that is translating the IP to something else.

@viragomann I thought it would not work because the additional encryption domains, are not local to the Sophos either But thanks, I will give it a try.