Hello, In the last few months, I did some extensive experiments with UVerse residential service with and without PFSense. Both general purpose and with IPSec tunnels to a colocation facility.
The primary defect I identified in UVerse itself was related to their router prohibiting you from altering or editing its default break-everything-inbound IPv6 configuration. Inability to work around it and use non-proprietary routers without flowing through the brain damage caused by their router led to switching to Comcast service in my case. I can say that generally you won't hit MSS or MTU problems in UVerse because it doesn't do textbook PPPoE stuff to mangle the L2 frames like classic DSL does. Most of my issues were actually caused by IPSec or PFSense version of it. Here are some items I have never seen put together in one place for the most reliable PFSense IPSec configuration. This is mostly walking through the screens in PFSense's order in its UI. This is assembled partly via IPSec PFSense wiki official pages, partly through a LONG list of assorted forum posts across many years I read, and a whole ton of testing and essentially endless swearing at my terminal across several weeks of work. If there's a way to give this back to the documentation pages or to people doing QA or Dev I would love to do so also. Matthew. Advice: 0. Always enable the debug logs recommended by this page: https://doc.pfsense.org/index.php/IPsec_Troubleshooting "Logging for IPsec is configured at VPN > IPsec, Advanced Settings tab. The most useful logging settings for diagnosing tunnel issues with strongSwan on pfSense 2.2.x are: IKE SA, IKE Child SA, and Configuration Backend on Diag All others on Control" 1. Always set the KEX to IKEv2 if at all possible. It allows doing IPv4 and IPv6 on a single P1 with IPv4 outer IPs only. 2. Use IPv4 as the P1 transport version. For obvious reasons, most exterior networks are brain damaged and can't do IPv6. 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. 4. On whatever side of a tunnel has a dynamic IP, if any, always use "Distinguished Name" as the Identifier. If you don't, a whole series of heinously insane stuff happens, which greatly increases the difficulty for the VPN Daemons to find the right PSKs or other credentials for the tunnel, and you get weird auth and crypto failures that make no sense. Note: this DNS name doesn't actually have to be defined or valid. It's basically a magic string. But you could define them in a DNS zone somewhere if you felt like it. Set the non-dynamic end to Peer IP, or anything else, but that one works well for me. Make sure this, and all other settings, are appropriately reciprocal from each side or stuff blows up in weird ways. 5. Unfortunately, in my case, connections always blow up and drop traffic, if "Disable rekey" is not checked on the Initiator end. This is really bad because these things are really supposed to be rekeyed. But if you don't fix it, SSHes and other important items don't just politely die, they freeze up unexplicably and get jammed up in the IPSec state machines never to apparently return. 6. Generally, check "Responder Only" on the non-dynamic side of the tunnel or things blow up. 7. Perversely, completely disable MOBIKE, regardless if both ends are static IPs or one is dynamic or not. It can cause the state machine epic fails described in Step 5, the same way the rekeying can. 8. Perversely, completely disable DPD also. It will nuke connections if it loses a packet here or there, and they don't re-establish cleanly. Instead, they get caught in state-machine hell, same as described in 7 and 5. 9. Make 100% sure the Routes / Networks in the P2s are right, or the tunnels will disagree about what to send each other from each end. Bad things can happen if you try to do stuff like 0.0.0.0/0 routes, when using an IPv4 IPSec outer tunnel, if you aren't careful, as non-tunnel traffic can get stolen by the selectors. To prevent weird stuff like that, you have to make sure that the Local Subnet entries, on the "Client" or "Less Central / Non Core Network" side of the tunnel are right. Very carefully read this page if using really broad Masks on one, other, or both ends of tunnel: https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel 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. Matthew. On Sat, May 13, 2017 at 06:48:48PM -0700, Laz C. Peterson wrote: > We???ll try that, thanks for the suggestion. > > I don???t recall us using that anywhere else ??? Would be great if it works! > > I???ll let you know. Thanks Jim. > > ~ Laz Peterson > Paravis, LLC > > > On May 13, 2017, at 3:57 PM, Jim Thompson <j...@netgate.com> wrote: > > > > > > Maybe NAT traversal? > > > > https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal > > > >> On May 13, 2017, at 5:30 PM, Laz C. Peterson <l...@paravis.net> wrote: > >> > >> Hello everyone, > >> > >> We???re having a pretty interesting problem here ??? > >> > >> To give you the quick summary, we have AT&T U-Verse ???Business Fiber??? > >> (which is a fancy way of saying it???s actual fiber, but the budget kind > >> ???) and have very serious issues establishing any TLS or SSL encrypted > >> connections through IPSec tunnels. > >> > >> If we plug a SonicWALL device in, same tunnel settings, we have no issues > >> at all. But our pfSense device (it is a SG-2440) struggles very hard and > >> we cannot do simple encrypted services over this tunnel ??? including > >> downloading email, synchronizing AD domain servers, or even rsync over SSH. > >> > >> It???s been very troubling. When plugging in the SonicWALL, all of these > >> services work completely flawlessly. The second we use the pfSense, none > >> of the encrypted protocols through the tunnel work. > >> > >> I???ve been thinking about MSS and MTU, but I really don???t know where to > >> begin. The SonicWALL seems to be able to figure these things out on its > >> own (if that???s even the issue). But I???m at a total loss. > >> > >> Any suggestions? > >> > >> ~ Laz Peterson > >> Paravis, LLC > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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
