Hi, the error was found and corrected in the VPN configuration on the AWS side.
The pfSense LAN subnet is entered there under "Local IPv4 Network Cidr".
The VPC subnet must be entered under "Remote IPv4 Network Cidr".
The solution for me was to use OPENVPN. Netgate informed me that there are some limitations in the free bsd software that cause this issue. I deleted my IPsec vpn and then built the site to site vpn using open vpn in pfsense. All my policy based routing worked fine after the switch.
I am new to pfsense and was used to using IPsec vpn's with other firewalls. I had never used open vpn therefore I started with IPsec. Open vpn is very simple to setup and works well. I am using it for site to site vpn with pfsense on both sides as well as for mobile vpn.
Hope this helps you.
Yeah, it's the other way around for me. Everything was working fine with OpenVPN but I needed to switch to IPsec because the bandwidth I'm getting with OpenVPN is limited by my hardware (APU2C4).
I consulted @jimp and confirmed that the workaround for this issues is this. The only caveat for setting that is it breaks policy-based IPsec tunnels, so if you use both route-based and policy-based then that would be a problem. As I'm using only route-based IPsec then I'm good. I'm testing now.
It's a limitation in FreeBSD and there isn't any way to know if/when it'll be fixed there. We may direct some resources toward it eventually but no ETA on when we might be able to do something like that.
In some cases you may be able to work around it. If most of your needs are for web-based services then HAProxy may be able to help. Client on far side hits HAProxy which proxies to internal host... Since the remote client is talking to HAProxy, and HAProxy is talking to the server, no need for reply-to.
For non-web-based services like Plex and Deluge where I need to port forward on the local end to access these servers on the far end, can HAProxy work? I tried outbound NAT with IPsec on the local end and it is not working. It works for OpenVPN just fine.
I manage to fix this problem with a better "option 3":
Unbound on the branch office forwards only the needed zones to the main office, while all other zones are being forwarded to public DNS servers (root or not).
Here's the complete step by step:
Make sure you have your preferred external DNS server set in System -> General Setup -> DNS Server Settings.
Run DNS Resolver on the remote pfSense box but for the "Outgoing" interface, make sure you use the "LAN" interface, not the WAN. This is needed so that the requests go across the tunnel.
Under the "Domain Overrides", enter the domains that you need to have resolved by the DNS at the main branch (i.e. ad.company.com) and the IP address of those DNS servers. You can also add the in-addr.arpa to those forwarding domains as well if reverse lookups are needed. If you have more than one server, duplicate the entry but change the DNS IP.
Change the DHCP server settings to used the LAN address of the pfSense box as their DNS servers.
In this case, when the tunnel drops, the only items that will fail to resolve will be the ones that specifically are forwarded to the main branch.
I have the same setup although instead of using LAN in the outgoing interfaces in unbound, I use localhost OR use both WAN and the IPsec interface (as I use Routed VTI). This works the same way as you did but I'm not sure if there's an advantage.
Turns out this is not related to high traffic via IPsec.
As it seems, this is related to ipsec tunnel only able to keep up 2 childs from 3 total. So at a givem time only 2 childs are operatable. If a new request from client comes that is routed via 3rd child, one of 2 active CAs gets disconnected and connections are lost.
Is this settings related, have I set something wrong, cant find anything related...
"Not My Cisco Router 2" had IP Address 220.127.116.11 instead of IP Address 18.104.22.168 on the original post's diagram. I do not think that this changes my questions.
The original diagram represent what is actually working using Cisco hardware.
The following diagram is what I presently I am presently doing:
pfSense IPsec Network.png
I am basically trying to replace the "My Cisco Router"
I have a working IPsec tunnel between LANS: 10.10.10.0/24 and 10.10.20.0/24. I did this to test if an IPsec VPN between two pfSense routers would work as expected and second check the configuration on "My pfSense Router". I can report that at least the tunnel between my pfSense routers works.
Nope in addition to port 21 you need to pass the passive port range, for eaxmple 10000-20000 but that that could be anything depending on how you've configured it.
Also vsftp seems to use ftps so needs port 990 also for the encryption.
You should not really have an issue with a Draytek to ASA VPN, we have many of those running on multiple ASA firmwares and 2820s, 2860s (v22.214.171.124), 2862s, 29xx etc.
I can't specifically tell you how, as I am not the Cisco guy :-) If it helps most of ours run on IKEv1 with 3DES with auth, no PFS. We also run all the tunnels outbound on the Draytek to the Cisco., with P1 28800 and P2 3600, which is the Draytek default.
The solution is reasonably well documented on the Draytek knowledge bases and forums, and your Draytek reseller should have access to Draytek tech support, who are pretty helpful most of the time if you are clear on what the problem is.
Not wishing to undermine stephenw10 on the pfSense sell ;-), we have had no luck really in getting Draytek to play with pfSense running in Azure. Despite our best efforts we cannot get a stable solution. We can get pfSense to work with ASA all day long though, so it depends which end you might switch out for a pfSense.
Right now I’m using a LastPass generated password 16 charachter and just saving the credentials . Just abit concerned about this approach as it’s just 1fa , I’m saving the password and the vpn gives full access to my network
Also, what does using certificates protect against ? Not sure on how it enhances security
After even more investigation:
Seams like the rules from WAN to pfSense where in place and effective. But what was missing: An allow rule from IPSec to the LAN. Is this "works as designed"? Even the DNS (the pfSense itself) was not reachable...
There is an ACME package in pfSense, works great for me and many others. YMMV depending on your update method, though.
I just tested, it works! thank you
Do I have to configure an "Action" in the ACME service so that it restarts IPSec server when renewing the certificate to take the new certificat or does it happen automatically without restart?
Regarding the NAT/BINAT configuration in the phase #2 I found this one:
I think this is what matches my case:
NAT - Overload/PAT Style
If the Local Network is a subnet, but the NAT/BINAT Translation address is set to a single IP address, then a 1:many NAT (PAT) translation is set up that works like an outbound NAT rule on WAN. All outbound traffic will be translated from the local network to the single IP address in the NAT field.
I think that my phase #2 configuration I posted above is clearly non-sense, isn't it? I'm talking about the translation configuration:
Local Network: Address 126.96.36.199
NAT/BINAT translation: Address 188.8.131.52
To me it would be logical to configure it this way:
Local Network: Network LAN subnet
NAT/BINAT translation: Address 184.108.40.206
Reconfigured it accordingly, but still no traffic. Leaves the previous question: Do I have to configure additional NAT settings apart from the phase #2 NAT/BINAT configuration?
What is more: I found this one https://forum.netgate.com/topic/140873/solved-inbound-traffic-with-nat-binat-translation-via-ipsec where it is claimed that not the site using a single IP address but the partner site has to configure NAT/BINAT settings. Now I'm rather confused.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.