Re: [pfSense] Moving traffic between LAN & OPT1

2017-12-24 Thread Matthew Hall

> On Dec 24, 2017, at 9:45 AM, Chris L  wrote:
> 
> Not a bug. That is by design. Create the rules to pass the traffic you need 
> to pass on OPTX interfaces after you create them.

That's inconsistent with the LAN interface which has secret undocumented 
default rules that allow self traffic to the firewall from the interface 
network segment by default. To me this inconsistency does feel like a bug. 

>> Again, not a bug.

There's a long open bug for it actually:

https://redmine.pfsense.org/issues/5826

It will break your configuration whenever you configure IPSec between an OPT* 
and a remote destination whose CIDR block happens to be a superset of your 
interface CIDR block and you have been using any local service like DNS, HTTPS, 
SSH, etc. on the firewall. The traffic will be misrouted through the tunnel due 
to missing logic for bypassing the firewall self traffic from the tunnel. 

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


Re: [pfSense] Moving traffic between LAN & OPT1

2017-12-23 Thread Matthew Hall
I did run into various bugs involving interfaces != LAN. One common one is that 
the other interfaces are missing a default allow rule for reaching pfSense on 
53/udp. This makes all your DNS requests fail and then it can seem like none of 
your stuff is working. Another problem you can find is, if you use IPsec or 
another site to site VPN, these other interfaces don't have a bypass rule 
preventing self-traffic to the firewall from being forced through the VPN 
tunnel. So I'm not sure what configuration you've got but there are some funny 
things you can see. I will say that once I worked around these items I was 
easily able to move or block traffic between LAN and the other interfaces with 
no issues. One trick that can help with the debugging is to replace the 
implicit default block rule with a default reject rule so you can easily see 
what's misconfigured on the end nodes and watch the firewall for log messages 
on your rules with logs enabled to see why your traffic refuses to flow. 

Matthew Hall

> On Dec 23, 2017, at 6:53 PM, Walter Parker <walt...@gmail.com> wrote:
> 
>> On Fri, Dec 22, 2017 at 8:25 PM, Antonio <m...@geotux.it> wrote:
>> 
>> Hi,
>> 
>> I'm not sure how you move traffic between the above interfaces. I was
>> under the impression that all you needed was a "Default allow LAN to any
>> rule" and job done. Yet i'm struggling to get devices of different
>> interfaces to communicate. What am I missing?
>> 
>> That rule allows the LAN to move traffic. Traffic on OPT1 is a different
> network. You will have addition rules to allow it talk to LAN. You will
> need to add two sets of rules (or floating rules) depending on how you wish
> to design your network.
> 
> 
> Walter
> 
> 
> 
>> 
>> 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.
>> 
>> ___
>> pfSense mailing list
>> https://lists.pfsense.org/mailman/listinfo/list
>> Support the project with Gold! https://pfsense.org/gold
>> 
> 
> 
> 
> -- 
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis
> ___
> 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] IPv6 1:1 NAT problems

2017-08-02 Thread Matthew Hall
This bug report is absolutely insane. It required more hours for people to 
compose these replies than it would to compose the patch for the actual bug. I 
couldn't even read it all because it was so violently toxic. 

Matthew Hall

> On Aug 2, 2017, at 9:36 PM, Morgan Reed <morgan.s.r...@gmail.com> wrote:
> 
> It's not "google" refusing to support it... It's one Lorenzo Colitti who is
> the roadblock...
> https://issuetracker.google.com/issues/36949085
> But yes, it's asinine.

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


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Matthew Hall
If you put your network segment into Assisted Mode the clients will try SLAAC 
followed by DHCPv6 so that things can cooperate between both approaches. 

Matthew Hall

> On Aug 2, 2017, at 8:00 PM, Adam Thompson <athom...@athompso.net> wrote:
> 
> You could be right, I was writing from memory and ... tbh, I don't care 
> enough to go look it up again :).  They shut down, that's a pain in the butt, 
> I was already on HE anyway, end of story for me.
> I would do the same here, except that (IMHO) Google's refusal to support 
> DHCPv6 on Android is completely asinine.  So my phone still doesn't get an 
> IPv6 address here at home :-(.
> (Note: Apple products work perfectly.)
> 
> It's interesting to speculate about what will happen at some future date when 
> HE turns off (or starts charging for) their tunnel service...  I haven't 
> heard anything credible yet, but I assume it'll happen someday.
> 
> -Adam

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


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Matthew Hall
https://tools.ietf.org/html/rfc6296

Matthew Hall

> On Aug 2, 2017, at 7:19 PM, Vick Khera <vi...@khera.org> wrote:
> 
> Is NAT even a thing with IPv6?
> ___
> 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] IPv6 problem at OVH

2017-08-01 Thread Matthew Hall
On Tue, Aug 01, 2017 at 11:27:50PM +0200, Olivier Mascia wrote:
> The real issue is that HA setup of a couple of pfSense is impossible with 
> such an awkward IPv6 setup as OVH imposes to us.

Just curious: how does it break CARP + pfSync?
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 problem at OVH

2017-08-01 Thread Matthew Hall
On Tue, Aug 01, 2017 at 01:57:01PM -0500, Adam Thompson wrote:
> *** As a consequence, all IPv4 addresses must respond to ARP, and all IPv6
> addresses must respond to NDP, in order to be successfully publicly routed.

The last time I had this issue, I had a Fortinet installed, and I used this 
featureset:

I don't think the PFSense currently exposes the NAT66 for configuration. When 
you use it, you can use an internal ULA subnet from a ULA generator, and use 
NAT66 to get the right exterior origin.

http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-IPv6-54/IPv6%20Features/IPv6_NAT.htm

It would be best solved using IPv6 VIPs for the inbound NAT. I have tested 
that and had it working on Linux and PFSense myself.

The other thing you can perhaps do, since they sent you a whole /56, is hand 
out /64s inside the PFSense that are chopped out of the /56 given to you. I've 
done that in my house using DHCPv6-PD from Comcast. But it should be possible 
with classic DHCPv6 and some static routes and/or a routing protocol inside 
your setup. It depends just how their layer 2 restrictions work. In my colo 
company it was fine because I didn't have to directly do ARP / NDP as long as 
I could route properly both ways.

> (NDP for an entire /56?  Fee fi fo fum, I smell a DoS attack...)

Yes.. this problem was called out during the lead-up to World IPv6 Day and 
World IPv6 Launch in 2011 and 2012.

https://en.wikipedia.org/wiki/World_IPv6_Day_and_World_IPv6_Launch_Day

Some patches to rate-limit the priority and request rate of new NDP neighbor 
adjacency discovery were added to the vast majority of major Cisco, Juniper, 
... etc. router firmwares.

Matthew.
___
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 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 <j...@netgate.com> wrote:
> 
> 
> 
>> On May 15, 2017, at 10:02 PM, Laz C. Peterson <l...@paravis.net> 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 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 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] looking for silent and powerful pfsense hardware

2017-03-28 Thread Matthew Hall
On Tue, Mar 28, 2017 at 08:13:54AM -0400, Vick Khera wrote:
> I would recommend at least a Xeon processor base system for that traffic.
> Really, the limit is PPS; do you know what that would be? Any system using
> a Xeon will not be silent. I use a pair of high end custom-built boxes at
> my data center, and they can push this kind of traffic, though my usual
> sustained is only in the 200Mbps range.
> 
> The only silent systems I have are based on the Atom C2758 processor, and I
> do not think those will handle a full gigabit connection at full speed.

This isn't right, the SG-2440 can do it.

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


Re: [pfSense] looking for silent and powerful pfsense hardware

2017-03-28 Thread Matthew Hall
On Tue, Mar 28, 2017 at 09:59:05AM +0300, Eero Volotinen wrote:
> Hi List,
> 
> Looking for pfsense hardware that can handle 1000M/1000M internet
> connection with NAT.
> 
> Any recommendations? It must be silent..
> 
> --
> Eero

This model can do gigabit with line-rate 64-byte packets:

https://store.pfsense.org/SG-2440/

If you don't need line-rate it's possible with some other units.

Can you provide more specifics on the traffic mix?

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