I wanted to come back and share what I have found.  I have been looking at this issue for the last few days and I have easily come across 20 posts sharing the link I provided above.  Each of these posts discusses getting the DHCP Relay to work with PFsense while using an IPSec tunnel.  One thread referenced here:

https://forum.pfsense.org/index.php?topic=6932.0

States that ssheikh back in 2008 actually got this to work by providing a dummy route back toward the DHCP relay machine from the other end of the IPSec link, but I have not been able to reproduce this.

Finally, in an effort to solve this, I submitted a support ticket.  In which I received the reply:

I have discussed your case whit our engineers and what you are trying to do here simply dose not work within pfSense alone, to achive this you need to use the IP Helper and DHCP Relay on the switches not on pfSense as it do not manage to send the reply back to the client, however you can still use the IPSec tunnel on pfSense

So unless someone has something to add here, this simply won't work at all.  HOWEVER….

I also found this thread:

https://forum.pfsense.org/index.php?topic=57769.0

That apparently allows you to pull in another DHCP relay package.  This package will allow you to bind to an IP address on the local pfsense box.  I found another thread referencing this and saying it functions well.  So this might deserve some follow up if you are really interested in making this work.

I accomplish what you request, using WAN groups and dyndns..

I attach my configurations, hope this helps you


Well this is sort of interesting.

I didn't really need my full subnet at SITE A available to SITE C so I trimmed it down so that SITE C now has access to the same 6 IP's that SITE B has access to.

Once I did that traffic routed for greater periods of time before disconnecting. Strangely, for the first day pinging SITE C from a Linux server at SITE A would allow a reconnect but it took 40-50 pings. Running a ping from one of my Win10 laptops would not allow a reconnect. I don't really think that's relevant, merely interesting. As before, when the traffic stops flowing, the tunnel shows as being still connected from both ends but pinging something on SITE C's LAN from SITE A fails. Pinging something at SITE A from SITE C results in a near immediate re-establishing of traffic. As one might expect, leaving a ping running between sites keeps everything working, but that feels more like a kludge than a solution.

I'm really stumped. SITE A has a 25MB Cable connection, SITE B and SITE C both have 50MB duplex fiber connections from the same provider. I have two more sites to connect to SITE C. SITE D is a rural location with a barely functioning DSL but it has an IPSEC tunnel between it's Cisco and a separate Cisco at SITE C that has been completely trouble free for years. It will be upgraded to a pfSense appliance shortly and the tunnel re-established. SITE E has a cable line and a Cisco so I'm eager to see if I get a different result.

You probably need to re-enable Unity.
https://doc.pfsense.org/index.php/Upgrade_Guide#Removed_features_that_are_disabled_on_upgrade

thank you CMB

Have you enabled the CISCO unity feature? - I think Chris had made a comment about this already.

You don't see this traffic when you do a packet capture on your interfaces directly from pfsense?

Haven't yet worked this out…

Any ideas why the reply to the initial FTP request has a source IP of the physical IP on my WAN Interface?  To the internet, the ISP NATs this to a global IP, but this isn't relevant I believe

State of this reply:

WAN -- tcp -- <wan ip="">:42390 --> <remote ftp="" server="" ip="" across="" vpn="">:21 -- SYN_SENT:CLOSED</remote></wan>

@cmb:

That doesn't match the P2 you have defined, so it's not supposed to go over the VPN. Needs to be source of the network, not single IP, like your other one.

I'm not quite sure what you mean. The given configuration is mandatory by the provider of the tunnel endpoint… It works using the same config on another router like a Draytek!

well and i dont know for exactly sure they are ALIX, but they are older red netgate units with 3 interfaces.  but they do keep repeatedly dropping their ipsec tunnels every day, and i constantly have to log into them and restart the tunnels.

i did have 2 even older and smaller silver netgate's whcih both did not survive the 2.3.x upgrade.  one died and woudlnt reboot, one repeatedly said corrupt update file.  replace them both with brand new units.

the rest of the history on this project is, previous consultancy deployed all these netgate units and used openvpn back to HQ (and never updated them).  old consultants were out out and i was in, their HQ moved to a new location/IP, so all these firewalls were left on their on for a few months (no VPN). when i finally get around to them and update them to 2.3.x and build IPsec tunnels back to HQ, now the tunnels (and often the internet as well) keep going up and down.  as the customer does not have any technical people working for them full time, all they see if firewalls that dont stay up after i upgraded/VPN'd them all.

so right now im grasping at straws trying to figure out whats wrong.  i have SO many other pfsense installs out in the field (all newer PCs or newer pfsense hardware) and these dinosaurs are the only ones giving me troubles.  but there are about 50% of the netgates that fall into the same age group that are working 100% fine.

A clean install with 2.3.1 and a quick setup of the ipsec site-to-site, came up straight away.

I played with the IKE settings between Auto, v2 and v1 - As cmb said,  my config must have been different when I was comparing.

Thanks…

Also, FYI- If you choose to use AES-GCM in P1 for an IKEv2 tunnel, use AES-XCBC for the "hash" algorithm (really it's a PRF in that case and not a hash…).

Ok, with the help of some experts we got it working. If you ipsec gives you a local network that is not your local network create a virtual ip that is that subnet. Then add a secondary ip in that network on your local computer. Add a static route on the computer. And it's up.  ;D

You can't do LAN and WAN with one interface like that, but you can do what you're describing with only WAN, no need for two interfaces.

Probably because it's getting a state leaving WAN before the VPN is up. Waiting allows the state to clear.

Add a floating rule to REJECT outbound on WAN for any destination matching your remote VPN subnet(s). That will stop the leakage.

@kapara:

what about under IPSEC status?  Do you have any Child SA's? or is only P1 connected?

Thank you for your answer.
IPSEC Status is fine and services ir running fine .
No child SAS.
Yes only one P1 connected right now

Thank you

ok thanks.  I am struggling to find a clear tutorial for this on 2.3.

I am going to try changing the MTU to 1400 tonight.

What is interesting is when I switched to 3des/sha1 from AES on the APU I was able to pass 3-4 mbit on windows file transfers compared to maximum 1.5 on AES 128/Sha1

With the new version 2.3 are we able to take advantage of all the strongswan commands?

I am running 2.2.6 and I lost all connectivity to the GUI during setup of a VPN.  Since I cannot reboot (Business Hours) I wanted to check the status of the VPN's and I was able to run from shell:  ipsec status and was able to get details on all configured tunnels.

https://wiki.strongswan.org/projects/strongswan/wiki/IpsecCommand

Can we use this to restart the ipsec or is that not recommended?

@cmb:

That's handled automatically.

Well that is good but for those that come from other firewall system, it is really an abnormally.  I would be better for the system assigned rules to be shown grayed out or even in a different color and not editable.  Thanks.