Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-15 Thread Matthew Hall
Try enabling and reading the debug logs first to scavenge some output from both 
tunnel ends. I found a lot of my brokenness enabling and reading the docs 
listed in PFSense's debug log listing wikipage for IPSec linked in my previous 
mails. It saves a lot of time over going in blind if you can catch some more 
specific issues from those logs. 

Matthew Hall

> On May 15, 2017, at 8:57 PM, Jim Thompson  wrote:
> 
> 
> 
>> On May 15, 2017, at 10:02 PM, Laz C. Peterson  wrote:
>> 
>> Is Openswan what is used for IPSec?
> 
> Strongswan. 
> 
> 
> ___
> 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


Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-15 Thread Jim Thompson


> On May 15, 2017, at 10:02 PM, Laz C. Peterson  wrote:
> 
> Is Openswan what is used for IPSec?

Strongswan. 


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


Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-15 Thread Laz C. Peterson
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  wrote:
> 
> Hi Jim,
> 
>> On May 14, 2017, at 6:38 PM, Jim Thompson  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 

Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-15 Thread Matthew Hall
Hi Jim,

> On May 14, 2017, at 6:38 PM, Jim Thompson  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, 

Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-14 Thread Jim Thompson

> On May 14, 2017, at 7:28 PM, Matthew Hall  wrote:
> 
> 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.

Trust me, they’ll see it.

> 
> 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.

Additional details would be great here.  Even better would be to open a bug on 
redmine.pfsense.org with these additional details.

> 
> 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" 

Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-14 Thread Laz C. Peterson
Matthew,

That is excellent information.

It really is a shame what AT does to destroy a perfectly good internet 
connection.

We can't wait to give these things a try tomorrow. Along with Jim's suggestion 
about NAT-T, we are hoping to have something that works proper.

The biggest troubleshooting fact that we are facing is the SonicWALL having 
zero issues, and when "hot-swapping" with the pfSense (meaning there are no 
changes on the remote side, and the IPSec settings in SW and pfSense are 
exactly the same) we start to exhibit these problems.

Will report back tomorrow. Much thanks to all for the suggestions!

~ Laz Peterson
Paravis, LLC

> On May 14, 2017, at 5:28 PM, Matthew Hall  wrote:
> 
> 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 

Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-14 Thread Matthew Hall
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 

Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-13 Thread Laz C. Peterson
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  wrote:
> 
> 
> Maybe NAT traversal?
> 
> https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal
> 
>> On May 13, 2017, at 5:30 PM, Laz C. Peterson  wrote:
>> 
>> Hello everyone,
>> 
>> We’re having a pretty interesting problem here …
>> 
>> To give you the quick summary, we have AT 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

Re: [pfSense] IPSec tunnels on AT U-Verse

2017-05-13 Thread Jim Thompson

Maybe NAT traversal?

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

> On May 13, 2017, at 5:30 PM, Laz C. Peterson  wrote:
> 
> Hello everyone,
> 
> We’re having a pretty interesting problem here …
> 
> To give you the quick summary, we have AT 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] IPSec tunnels on AT U-Verse

2017-05-13 Thread Laz C. Peterson
Hello everyone,

We’re having a pretty interesting problem here …

To give you the quick summary, we have AT 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