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! [image: 1572340623119-screenshot_20191029_101321.png] In the Status / Interfaces there is no hidden blank behind it. [image: 1572340856947-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?

yes, it's work ;) and ping with -S flag work too without static route

Noone has any ideas, are ther any logs or such I can supply to enlighten things?

Firewall --> Rules --> IPSec was where I needed to be Have it working now