So, I've installed OPNsense and it seems to work properly there with a basic NAT port forward rule. I'm gonna do a couple more tests with different hardware on pfsense, but I suspect there're some issues with port forwarding rules on pfsense regardin IPSEC.

Edit: I've reset pfsenseA to factory defaults and set it up again. It was basically the same as the previous install but something went different this time. Now it seems to work properly.

@enthu19
Hello

Show phase 2 settings and rules on Lan and IPSEC interfaces There is no need to configure NAT OUTBOUND for IPSec tunnel (/Firewall/NAT/Outbound) There is no need to configure NAT Reflection for IPSec tunnel.

@Konstanti Thanks mate. Much appreciate it.

@ngoehring123 Yeah. Can't help you with the latency. Glad it helped.

Ok, all that blocked traffic you're seeing is TCP flagged traffic that is out of state. It's either blocked because the states have already closed, probably the case on that :PA traffic, ot because the states were never opened, usually due to rouet asymmetry.

https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html

You should be trying to find out why that is happening not just trying to pass the traffic anyway. Remove any floating rules you added there. You should not be seeing asymmetric traffic if this is setup correctly.

I assume pings work fine from the policy routed clients?

If you run a packet capture do you see both requests and replies at all points in the path?

Steve

So I managed to fix it in the end, seemed the issue was the IKEv2 P1 connection on the XG1541's side. I added the public IP as an attribute in the RSA cert and it seemed to then hookup fine - weird how there was no report of this failure though...

James.

That isn't a bug, it's a configuration problem. It definitely does do fallback in the right scenarios but it depends on how you have the DNS Settings/Resolver settings configured. You should not rely on servers that hand out different data. All of your configured forwarders should provide the same data.

That's a topic for a different thread, however.

@Morlock It should do nat yes, but as far as I know it's not working. Others firewalls like vyatta and Fortigate do. Take a look at this https://pt.slideshare.net/NetgateUSA/routed-ipsec-on-pfsense-244-pfsense-hangout-june-2018 (page 7).

@Derelict

Okay, I have tested it.
The result with my IP address is VALID IPv6 address.

Can it be that behind the IP address is a hidden blank?
In the Dashboard Interfaces behind my address is also a hidden blank!

Screenshot_20191029_101321.png

In the Status / Interfaces there is no hidden blank behind it.

Screenshot_20191029_101757.png

@dragoangel
Maybe https://forum.netgate.com/category/30/bounties
If you really need it and are willing to pay for it.
Else the best you can do is hope that it will come some time...

@prx first of all your second phase2 is absolutely incorrect - you cross 2 different network. You can try 2 different cases (first one more good):

Change OpenVPN subnet to be next subnet after your LAN like 192.168.1.0/24, and after it create only one Phase2 with 192.168.0.0/23 Use BNAT to 1 /32 IP on LAN subnet and reserve this IP in DHCP for not existing static IP so nobody will use it really NEVER in your LAN. I doesn't sure if even this will fix because even this is network collision

And another question: why you configured 3DES and use 1024 bit key group - this is too low? It totally deprecated... This is due old gw on other side of ipsec?

we need more information
check the log and report here
Status / System Logs / VPN / L2TP (Service\Login)

@bramqu

I have the same setup and can not get it to work van you please sent me the working config as well?

Kind regard
Mark

Courtesy of AWS support this issue was due to the following:

I selected BGP routing in the pfSense AWS VPC Wizard IPSEc tunnels were ESTABLISHED (UP), but BGP was stuck in 'Connect' state and hence "DOWN" The peer-proposal SA was created as : 172.16.0.0/24 --> 192.168.0.0/16 which implies that both the tunnels were configured as 'Policy based' VPN. This also implies that BGP was not configured on the XG-7100 device for the VPN (because BGP is 'Route'-based VPN always).

They suggested the following resolutions:

Recreate the VPN in the AWS Console using "Static" routing instead of "Dynamic" Configure BGP as per 'Download configuration' on the customer gateway device [Note: I expected the AWS VPC Wizard to do this for me]

I deleted the resources and started the pfSense AWS VPC Wizard from scratch, selecting Static routing instead, and this time it succeeded and enabled me to ping the EC2 host in the private subnet from the XG-7100.

@markvanderhurk

Maybe it's some kind of internal system failure, because I have not met with such an error yet. And I don't think that Strongswan is not able to count the length of the message (sadb_msg).

Did you ever get a solution to this missing route problem on Windows 8?