Re: [pfSense] Finding the best network setup for pfsense.

[Laz C. Peterson]

Hello,

A couple words from our experiences …

We have quite a few firewalls and many services offered publicly depending on 
which site you’re talking about, and we’ve learned that it really doesn’t pay 
off to try and micro-mange the firewall.  pfSense is done well, so by default, 
you can feel good about not really playing with the settings.  If you want 
security, you really want to have VPN to any clients that are going to access 
your network.  Don’t be opening up ports on the firewall.  So if you wanted to 
have access to your internal network, you could set that up easily with pfSense 
and the client for your OS.

If you wanted to do public services, like a web server etc, then it is what it 
is.  You’ll get hit by who knows what.  People scan IPs and ports all day long. 
 It doesn’t stop.  But then just open the ports, send them to your internal 
sever and call it a day.  No need to worry about those things at the pfSense, 
unless you start having issues (then you can look into security features in 
pfSense).

Blocking private networks is a necessity (unless you have weird network 
requirements) because no WAN IP should have a private address trying to 
communicate with your pfSense.  That would be bad news.

The proxy is great.  You’ll love it for your kids.  Just make sure to disable 
their cellular access ;-) …

Regarding routing, we always make separate subnets.  One internal subnet would 
be “home” and the other would be “work”.  Work network gets to connect to VPNs, 
home does not.  Each network carries its traffic separately internally and to 
the internet, and they cannot communicate with each other.  We do have some 
cases with AppleTV that we want to have mDNS and communication between subnets, 
so we do make special consideration for those — but it’s rare.  But that may be 
of use to you … Streaming devices are always fun to get working with a complex 
(but optimal!) network.

Just some thoughts for you.  Good luck!

~ Laz Peterson
Paravis, LLC

> On Dec 22, 2017, at 6:34 PM, Antonio  wrote:
> 
> You are probably right so I have gone and disconnected the Hawk. I'm a
> bit worried now that my WAN is exposed to attacks. Is it sufficient to
> have the "Block private networks" and "Block bogon networks" active on
> the WAN interface? Any other rules needed?
> 
> 
> Thanks
> 
> Respect your privacy and that of others, don't give your data to big 
> corporations.
> Use alternatives like Signal (https://whispersystems.org/) for your messaging 
> or 
> Diaspora* (https://joindiaspora.com/) for your social networking.
> 
> Il 23/12/2017 00:29, Ryan Coleman ha scritto:
>> I think the overkill is all the extra appliances doing things that
>> pfSense can do.
>> 
>> You want the pfSense to be in the middle, you want the traffic to be
>> filtered and routed… pfSense is great for this very task, you don’t
>> need the Hawk or Netgear firewalls… 
>> 
>> aDSL modem -> pfSense -> switch -> Rest of network
>> 
>> 
>> 
>>> On Dec 22, 2017, at 6:15 PM, Antonio >> > wrote:
>>> 
>>> Sounds cool but maybe a bit overkill for what i need ...
>>> 
>>> Cheers
>>> 
>>> Respect your privacy and that of others, don't give your data to big
>>> corporations.
>>> Use alternatives like Signal (https://whispersystems.org/) for your
>>> messaging or 
>>> Diaspora* (https://joindiaspora.com/) for your social networking.
>>> 
>>> Il 22/12/2017 22:35, Eero Volotinen ha scritto:
 Well,
 
 Just plug pfsense to ADSL and buy managed switch and some unifi wlan
 aps. You can install proxy on pfsense box also..
 
 
 Eero
 
 22.12.2017 23.57 "Antonio"  >
 kirjoitti:
 
Hello,
 
I'm trying to design an optimal network setting for my home and was
wondering what people's thoughts were based on my needs:
 
1) Need a single DHCP, DNSMasq server;
 
2) want to route traffic through VPNs only on certain parts of my
network
 
3) want to eventually install a proxy somewhere on the network to
route
traffic from my kids laptops/tablets.
 
4) obviously want to firewall all centrally as best as possible.
 
My setup is as follows:
 
a) I have a little compact mini PC with four ethernet connections (1x
WAN and 3x LAN) - its wifi too
 
b) A Netgear Modem onto ADSL
 
c) A Netgear router Hawk 7000
 
d) a couple of desktop PCs wired to (a) as well as a server
 
e) several mobiles, IoTs that connect wireless to (c)
 
At the moment the connection is (b)->(c)->(a)->PCs but I feel I'm not
getting the best of this setup, particularly pfSense which at the
moment
is just firewalling my PCs/server.
 
I generally consider the wifi network the weak point as guest
 come and

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

[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

[Laz C. Peterson]

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

___
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

[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 <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 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] IPSec tunnels on AT U-Verse

[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