@johnpoz Correct. CGNAT is being rolled out, so I’m trying to switch anything that might be affected to v6.

@aneeshksurendran9007 If your current phase 2 doesn't cover the OpenVPN tunnel network, you need a second one. IPSec phase 2 must always be added to both sites. You can circumvent this, however, by natting the VPN clients access to an unused IP of the existing p2 at the main office.

@user-ng2100 Im also new!!! Nice to know that there's someone like me who are a beginner. Btw i dont know the answer, i just wanted to say hi, if i know someome who knows, ill let you know

@oscar-pulgarin Do you have multiple phase 2? If so you have to move this one up. Do you need access the remote site, or are your only expecting incoming connections? For incoming traffic add a rule to IPSec. For connections to the remote site, add rules to the respective incoming interface.

@viragomann Hmm, is that common? I only have two routers in this case that I can test, and they don't do masquerading...

@Gblenn I will have a look at that, I did a bit of reading around that last night, but didn't delv deep enough etc. Thank you

@Spyderturbo007 Assuming it is a hub and spoke topology: main site: first phase 2: 172.16.1.0/24 -> 192.168.50.0/24 172.16.0.0/24 -> 192.168.50.0/24 second phase 2: 172.16.1.0/24 ->172.16.0.0/24 192.168.50.0/24 -> 172.16.0.0/24 site 192.168.50.0/24 192.168.50.0/24 -> 172.16.1.0/24 192.168.50.0/24 -> 172.16.0.0/24 site 172.16.0.0/24 172.16.0.0/24 -> 172.16.1.0/24 172.16.0.0 -> 192.168.50.0/24

@dochy Hey! Have you a solution for this problem? We have currently the same..."error writing to socket"

@unsichtbarre No, it's not possible to route the traffic properly if the remote networks overlap. You have to either change or translate one. But both of this have to be done on a remote site. You can ask one of them to nat it for you.

@arrcy said in How to portforward over ipsec vpn: I want incoming connections on siteA:766 to be port forwarded to 192.168.2.100:766 over the ipsec tunnel Across a policy-based IPSec, this is only gonna to work if you either do masquerading on site B LAN2 with an outbound NAT rule or if you route the whole upstream traffic from B over A. The latter might not be desirable, I guess, the former has the drawback that you loose the information about the origin source IP. It would work without this limitations with any other kind of VPN: routed IPSec, OpenVPN, Wireguard preferably i also want Lan 3 and lan 1 also be able to access 10.0.0.1 without adding extra ipsec configuration but using outbound NAT Just add a phase 2 for each subnet pair, you want to connect. LAN1 <> 10.0.0.0/24 LAN3 <> 10.0.0.0/24 Remember, that you have to add these p2 with exchanged local - remote networks.

@Gblenn Actually site B has minimal services, no suricate, snort pfblocker or anything else installed. I'm clueless.

@viragomann the mint firewalls on both ends are allow any any

@bitvoip I’d just submit a bug report in that case… …costs nothing and ensures it’s on the radar of the developers.

@mauro-tridici I have seen a case where the ISP modem (Comcast) was apparently blocking the inbound port forwarding. Changing the pfSense to a different WAN IP let it work. Re upgrade: https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting

@nabberuk I know this is an old topic, but replying here for the record as I had a very similar issue where I was unable to get multiple P2s to connect. In the advanced settings, if you check the "Split connections" setting which is described as "Enable this to split connection entries with multiple phase 2 configurations. Required for remote endpoints that support only a single traffic selector per child SA." that seemed to get the IPsec connection working between pfSense and Sophos.

@keyser Thanks a lot for the clarification. Everything is now working as expected.

@mvbif Policy-based IPSec strictly connects two networks in a phase 2. And only these two network can communicate. If you forward traffic from a public IP the source might be outside of these network. So the packets won't be accepted. Yes, there are two possibilities with policy-based IPSec. You can either source-NAT the packets. But this must be done in the IPSec phase 2 with BINAT and to an IP, which the remote site has defined as remote network in its p2. Conventional outbound NAT would not work. The second option is to state 0.0.0.0/0 as local network on site 1 and as remote on site 2, but this means, that all upstream traffic from 2 will be routed to 1, which might be undesired. With VTI, you can assign an interface to the IPSec instance at site 2, where you have to define the firewall rule for inbound from the remote site. So pfSense can apply the reply-to tags to the packets, which is necessary to route response packets back to site 1.