Matthew and Jim,

We didn’t get a chance to test anything today.  It turned out to be “one of 
those Mondays” … But there’s something really weird going on.  I know nothing 
about the subject compared to Matthew — and he claims he knows nothing about 
it.. Ha ha …

Is Openswan what is used for IPSec?  Maybe there’s information specific to 
Openswan that someone else has run into (that wouldn’t turn up on a “pfSense” 
search).  I haven’t had a chance to check yet.

Hoping to study and learn about what you all have discussed here.  Maybe will 
get a chance to test by the end of the week.

Thanks so much.

~ Laz Peterson
Paravis, LLC

> On May 15, 2017, at 11:54 AM, Matthew Hall <mh...@mhcomputing.net> wrote:
> 
> Hi Jim,
> 
>> On May 14, 2017, at 6:38 PM, Jim Thompson <j...@netgate.com> wrote:
>>> 3. Create one or more P2s to make selectors for traffic inclusion and 
>>> exclusion. Note there's a bug in PFSense, where if you do IPSec from 
>>> not-LAN 
>>> interfaces, the traffic to the firewall's IP gets stolen unless you 
>>> manually 
>>> hack the PHP file that generates the IPSec traffic selector configuration, 
>>> to 
>>> whitelist more interfaces. This prevents being able to do Ping, DNS, NTP, 
>>> etc. 
>>> all other services against the firewall on non-LAN if IPSec is on. Bad 
>>> times 
>>> right there.
>> 
>> Additional details would be great here.  Even better would be to open a bug 
>> on redmine.pfsense.org with these additional details.
>> 
> 
> I did discuss this problem previously in the mailing list and forum. I was 
> seeking some views on the topic, before I went forward with filing a defect, 
> as IPSec traffic selectors are an area I don't profess to understand 
> incredibly well, and I wasn't 100% sure I didn't miss something in my 
> analysis, and didn't want to generate a bogus bug if so.
> 
> I found this when creating a restricted LAN on the OPT1 port that was allowed 
> to use IPSec when the LAN connected to the LAN port was not supposed to use 
> IPSec. Basically, it's a DMZ network inside a house, walled off from the 
> normal network, with a separate wireless SSID and separate Ethernet ports, 
> which is then IPSec connected to a colo facility, w/ the PFSense IPSec on 
> both ends.
> 
> The issue happens here:
> 
> https://github.com/pfsense/pfsense/blob/e470f72139ed54972465e653e27536687ce58b23/src/etc/inc/vpn.inc#L807
> 
> If you look at this code, it doesn't exempt all of the firewall's own IPs or 
> at least Internal IPs from getting captured by the IPSec selectors for any 
> tunnels. So management / admin traffic / other helpers to and from the 
> firewall, like Ping, DNS, NTP, DHCP / SLAAC, etc. don't get through or don't 
> get replies because only the LAN IP gets exempted when the UI Checkbox for 
> bypass is checked and not all of the other interfaces (or specifically chosen 
> interfaces... it only has a checkbox for LAN and not for any others). Also 
> it's only exempting IPv4 so IPv6 will get broken even more than IPv4 will, if 
> you're doing IKEv2 w/ IPv6 tunnels on top, which I use heavily in my case.
> 
> I "fixed it" by hand-editing this file that generates the VPN setup to make 
> more bypass exemptions, and promptly watching the issues stop happening after 
> I added this hack.
> 
>> Don’t know what you mean by “broad”, but it’s all (multiple) /24s here.
> 
> It took quite some time, for example, to get ::/0 in IPv6 routing across my 
> tunnel w/o malfunctions. And the same would apply using 0.0.0.0/0, and it was 
> very critical to read and follow this document, and the logical equivalent 
> behavior for IPv6, to the letter for it to work.
> 
> Regarding when the issues hit exactly... it can happen if you aren't really 
> careful to make sure that the selectors grabbing big swaths of IP space on 
> one tunnel end, aren't carefully restricted to a narrow range of IP space on 
> the other tunnel end. It's not saying PFSense did something wrong, but more 
> that with the IPSec stuff, you have to be extremely judicious with the setup 
> of the selectors, to prevent them from stealing unexpected traffic and 
> sending it in the tunnel. If you make typos here or mess up, you can make 
> your firewall unreachable (especially w/ the bypass issues I wrote about 
> above), and have to come in from the console to roll things back if they 
> aren't set up 100% perfectly.
> 
>>> 10. Instead of the MOBIKE and DPD crap, keep the tunnel up, by using valid 
>>> IPs 
>>> on PFSense on other end of tunnel in the P2 auto-ping host entry. This will 
>>> keep the IPSec up all the time and keep it from getting foobarred, unless 
>>> the 
>>> link itself has a gnarly outage, in which case you're down regardless.
>>> 
>>> 11. On both the P1 and P2, lock down the list of KEX, Enc, and Auth 
>>> algorithms 
>>> to a single solid algorithm. If the negotiation screws up, it causes weird 
>>> connection problems which you will damage your brain trying to debug.
>> 
>> All of this is of interest, and deeply appreciated, but I’ve got an IPsec 
>> connection between home and work that has been stable since … a couple years 
>> ago.
> 
> I have very reliably working connections now as well, but only after hacking 
> on vpn.inc as described above, and only when MOBIKE, DPD, Rekey, are all 
> disabled. Otherwise, in my case, when the tunnel times out due to rekey, 
> MOBIKE, DPD, detecting drops or relocation of anything, the renegotiation 
> that gets triggered seems to get stuck, and all the traffic going through the 
> tunnel is getting blocked.
> 
> It's surely possible the UVerse router was causing the brokenness. I can play 
> with the settings some more on the cleaner Comcast connection to see if I can 
> reproduce it again.
> 
> I forgot to mention another item, in the last go-around, which seemed to 
> prevent me from getting as many IPSec tunnels stuck, timeouts, etc.: I always 
> set System -> Advanced -> Firewall & NAT -> Firewall Optimization Options to 
> Conservative on both ends of the tunnel. It seems to prevent the various 
> sockets for IKE, IPSec, NAT-T, etc. from getting closed as aggressively if 
> traffic is quiet for a while.
> 
> In my case, I couldn't really reliably configure my tunnels to the Initiator 
> + Responder mode, because most of my endpoints are Dynamic on Client side and 
> Static only on Colo Provider side.
> 
> Matthew.
> _______________________________________________
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Reply via email to