[pfSense] IPv6 cross-LAN access problem to virtualized host

[Bryan D .]

I'm in the process of enabling IPv6 on a working IPv4 3-LAN, 2-WAN setup using 
pfSense 2.2.6 (I'm also in the process of testing 3.0 and did a cursory test 
and got the same results with our 3.0 test setup).  We're getting IPv6 via a 
Hurricane Electric tunnel.

There are 3 LANs each with a /24 IPv4 and a /64 IPv6 subnet (the /64's being 
from the /48 allocated from HE).  Currently, incoming IPv6 WAN and WAN_IPv6 
access is blocked for all IPv6 except that ICMP types (other than redirect) are 
allowed.  Rules exist allowing unrestricted IPv6 access across all 3 LANs.

I have pfSense configured for DHCP6 on all 3 LANs and RA (on all 3 LANs) is set 
to "Assisted" and (maybe unnecessarily?) "RA Subnet(s)" is set to all 3 of the 
/64 subnets.

Each of the 3 LANs is also it's own VLAN.  There are 3x HP 1810 v2 switches 
across the network.

One of the hosts, the problematic one (and, of course, the only one for which 
we actually want IPv6), is a virtualized OS X 10.8.5 running under VMware 
Fusion 7.1.2 (also on OS X 10.8.5).  The VM host system has 2 VLANs and the VM 
guest has 2 NICs, one bridged to each of the VM host system's VLANs.

Multiple systems on the network, including the "problem" virtualized host, have 
multi-homed IPv4 and (of course) multi-homed IPv6 interfaces.  For simplicity, 
I've manually set the IPv6 addresses and am using only them for testing.

Everything works wonderfully, except that ...

I'm having a problem accessing the IPv6 IPs on the virtualized/guest system's 
interface that's bridged to VLAN3 of the VM host.  Accessing IPv6 and IPv4 
addresses on VLAN1 and VLAN2 works fine.  Accessing IPv4 addresses on VLAN3 
works fine.  "Sometimes" (see below) one of the 2 manually assigned IPv6 
addresses on VLAN3 can be accessed.

[Because of what (at least "sometimes") works, I conclude that neither pfSense 
setup nor a local host firewall is the problem.]

Here's the symptoms:

- boot the problem/virtualized host then, on another system (C) on VLAN1, run 
ping6 against both of the 2 IPv6 addresses on (the interface that's bridged to 
the virtualized host's) VLAN3 and I get "...from  -> 
: Destination Host Unreachable" (addresses are 
config'd and up, according to ifconfig but they're not listed in pfSense's NDP 
table, so this makes [pf]sense).

- on the virtualized/problem host, run ping6 against the other system C, and 
it's OK

- now, again run (the same) ping6 commands from the other system (C) on VLAN1 
against both of the 2 IPv6 addresses on the virtualized host's VLAN3 and it 
works against the first IPv6 listed via ifconfig, but not the second

[I'm assuming that the ping6 run from the virtualized/problem host caused 
pfSense to acquire the one IPv6 IP and that's why it's now accessible -- 
indeed, that 1 of the 2 VLAN3 IPv6 addresses is now in pfSense's NDP table.]

- run ping6 from the VM host system against both of the 2 IPv6 addresses on the 
(VM guest) virtualized host's VLAN3 and both work

[I'm assuming, due to the bridging, that local neighbor discovery works from 
the VM host to its VM guest.  pfSense does not acquire the additional IPv6 
address from VLAN3.]

Tests run from other hosts show results that are consistent with the above 
tests.  So, with 1 exception, everything works and is consistent with what's 
shown in pfSense's and various host's routing tables and via ifconfig.

The failure is that neither of the 2 IPv6 addresses (nor the auto-allocated 
private IPv6 address) from the interface (on the virtualized host) that's 
bridged to the VLAN3 interface are learned/acquired by pfSense unless a ping6 
is run from the virtualized host and then only the first ifconfig-listed 
manually assigned IPv6 address is acquired by pfSense.  As such, pfSense 
considers the IP(s) unreachable.

I'm guessing that there's an issue where OS X is either not reporting the 2nd 
interface (i.e., second in that the VLAN1-linked interface is ordered first in 
the network configuration) or that the bridging is interfering with that 
communication.

I'm assuming that pfSense is "asking" hosts to report via each RA-config'd 
subnet every "now 'n then" and, as such, VLAN3 is receiving such queries.  
(Hmmm, as I write this, maybe this is another thing to look at.)

QUESTIONS:

- has anyone experienced a problem anything like this and, if so, what were you 
able to do about it?

- what's the best way to go about confirming that the virtualized host is 
receiving whatever queries RA is sending out on VLAN3 (assuming that's what's 
happening)?  I do have packet-capture capability on the VM host and the 
virtualized/problematic host ... but is there anything simpler?

- does anyone have any ideas on how I might solve this issue and/or learn more 
about exactly what's happening?

My next attempt will be to configure rtadvd to run on the virtualized/problem 
host (with rltime 0) in an effort to get it to tell pfSense that the second 
interface is present ... but, from what I see in the man page, 

[pfSense] Soeckris Net5501 SSD

[Karl Fife]

I have about 15 Net5501's OR Lanner FW-7541D's in the field running 
embedded/Nano on CF cards.  There's not enough space on a 1GB  CF to 
upgrade to v2.3.  Of course I can upgrade to larger CF cards, however 
the eventual phase-out of NanoBSD makes me wonder if it's better to 
install a SATA SSD (or SATA DOM) which would possibly eliminate the need 
to re-re-factor storage in the near future (e.g with the release of v 
2.4, and the phase-out of NanoBSD: 
https://doc.pfsense.org/index.php/Upgrade_Guide#Planning_for_the_Future )


Question:
I'd like to ask what solid-state storage others are using on non-NanoBSD 
installs.  If running the "full" version of pfSense, Is it sufficient 
'simply' to use a quality wear-leveling SATA DOM, or is it recommended 
to use something with even better write endurance?  I wouldn't have 
thought the pfSense write load is high, but blog posts from early 
adopters of SSD's + pfSense seem to have run into write endurance 
problems.   SSD's have improved greatly especially in terms of 
wear-leveling, over-provisioning etc.. What's a recommended non-disk 
drive for full pfSense these days?










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

Re: [pfSense] firewall rules with fqdn-alias

[Martin Fuchs]

Hi, Steve !
No dots in the alias, yurt in the fqdn-address, the lookup works fine, so the 
resolved fqdn are visible in the tables, but it seems as if the rule is not 
applied.
But there is no error...
Any diagnostic hints ?
Regards,
Martin

> Are you using dots in your FQDNs? Those aren't valid alias names... 'The name 
> of the alias may only
> consist of the characters "a-z, A-Z, 0-9 and _".'
> 
> --
> 
> Steve Yates
> ITS, Inc.
> 
> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Martin Fuchs
> Sent: Tuesday, May 17, 2016 9:26 AM
> To: list@lists.pfsense.org
> Subject: [pfSense] firewall rules with fqdn-alias
> 
> Hi !
> 
> We're using pfSense 2.3_1 here in a CARP-cluster.
> 
> We are using rules with fqdn-aliases and those rules do not work.
> 
> When i look under diagnostics -> tables i see the tables filled with the 
> correct IPs.
> 
> When I change the rule not to use the alias, but the IP instead, the rules 
> works immediately.
> 
> It's really weired.
> 
> Does anyone have some idea for me ?
> 
> Regards,
> 
> martin !
> 
> ___
> 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] Zero Trust Networks

[Randy Morgan]

Hi Jim,

I have been reading a lot and the NIST document is actually printed and 
sitting on my desk.  I would love to talk with you privately, feel free 
to call me, or we can setup a time to meet in person, just give a few 
different times that you are available and I can see which one works for 
me and put it in my calendar.


Randy

Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100

On 5/17/2016 2:54 PM, Jim Thompson wrote:

Hi Randy,

Ex-BYU student here.  M.E. ’84, but I started in Chem, and maintained a vacuum 
distillation apparatus in the basement of ESC that was part of the Chem 
departments research in lasing emulsion dyes.
I have a relative (Steve Walker) in the English department, too.

If you’ve read the original Forester / NIST paper(*), there are three tenants 
to the Zero Trust Model:
• Ensure all resources are accessed securely regardless of location.
• Adopt a least privilege strategy and strictly enforce access control.
• Inspect and log all traffic.

We are in the process of building a segmentation gateway, leveraging Open 
Daylight as a controller, but this isn’t going to be “pfSense”.  It will be a 
Netgate product.

I don’t really talk about it much outside Netgate.  There are a few people here 
working on it (one of them just up the road from you in SLC.)

The idea is that one could then take pfSense 3.0, which is being re-architected 
to have a central management console (this used to be called “pfCenter” or 
“pfCentral”), and manage pfSense as a (set of) distributed access nodes.
This also serves to explain why we’re making the investment in ARM hardware 
(see several recent tweets, 
e.g.https://twitter.com/gonzopancho/status/731245772721651712), though that 
side will scale to multicore as well.  We can take the same userland-based 
(DPDK/netmap) networking codebase and running it on anything from a tiny ARM to 
a device with a dozen 40G interfaces and dozens of cores.

If you’d like to speak (privately) about this, I’m happy to do so, but I’m not 
ready to share further details publicly.  (Heck, most people here don’t know 
that this is one of the potential uses for what we’re building in the lab.  :-)

Aloha,
Jim
(*) 
http://csrc.nist.gov/cyberframework/rfi_comments/040813_forrester_research.pdf


On May 17, 2016, at 3:17 PM, Randy Morgan  wrote:

I have been doing some reading on zero trust networks, there is much to learn 
and this is a major paradigm shift in security thinking.  Can pfSense be 
configured to work in zones without a trusted zone, or is that something that 
is planned for a future release?

Randy

--

Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100

___
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] Zero Trust Networks

[Jim Thompson]

Hi Randy,

Ex-BYU student here.  M.E. ’84, but I started in Chem, and maintained a vacuum 
distillation apparatus in the basement of ESC that was part of the Chem 
departments research in lasing emulsion dyes.
I have a relative (Steve Walker) in the English department, too.

If you’ve read the original Forester / NIST paper(*), there are three tenants 
to the Zero Trust Model:
• Ensure all resources are accessed securely regardless of location. 
• Adopt a least privilege strategy and strictly enforce access control.
• Inspect and log all traffic.

We are in the process of building a segmentation gateway, leveraging Open 
Daylight as a controller, but this isn’t going to be “pfSense”.  It will be a 
Netgate product.

I don’t really talk about it much outside Netgate.  There are a few people here 
working on it (one of them just up the road from you in SLC.)

The idea is that one could then take pfSense 3.0, which is being re-architected 
to have a central management console (this used to be called “pfCenter” or 
“pfCentral”), and manage pfSense as a (set of) distributed access nodes.
This also serves to explain why we’re making the investment in ARM hardware 
(see several recent tweets, 
e.g.https://twitter.com/gonzopancho/status/731245772721651712), though that 
side will scale to multicore as well.  We can take the same userland-based 
(DPDK/netmap) networking codebase and running it on anything from a tiny ARM to 
a device with a dozen 40G interfaces and dozens of cores.

If you’d like to speak (privately) about this, I’m happy to do so, but I’m not 
ready to share further details publicly.  (Heck, most people here don’t know 
that this is one of the potential uses for what we’re building in the lab.  :-)

Aloha,
Jim
(*) 
http://csrc.nist.gov/cyberframework/rfi_comments/040813_forrester_research.pdf

> On May 17, 2016, at 3:17 PM, Randy Morgan  wrote:
> 
> I have been doing some reading on zero trust networks, there is much to learn 
> and this is a major paradigm shift in security thinking.  Can pfSense be 
> configured to work in zones without a trusted zone, or is that something that 
> is planned for a future release?
> 
> Randy
> 
> -- 
> 
> Randy Morgan
> CSR
> Department of Chemistry and Biochemistry
> Brigham Young University
> 801-422-4100
> 
> ___
> 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] Zero Trust Networks

[Randy Morgan]

I have been doing some reading on zero trust networks, there is much to 
learn and this is a major paradigm shift in security thinking.  Can 
pfSense be configured to work in zones without a trusted zone, or is 
that something that is planned for a future release?


Randy

--

Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100

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

Re: [pfSense] firewall rules with fqdn-alias

[Steve Yates]

Are you using dots in your FQDNs?  Those aren't valid alias names... 'The name 
of the alias may only consist of the characters "a-z, A-Z, 0-9 and _".'

--

Steve Yates
ITS, Inc.

-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Martin Fuchs
Sent: Tuesday, May 17, 2016 9:26 AM
To: list@lists.pfsense.org
Subject: [pfSense] firewall rules with fqdn-alias

Hi !

 

We're using pfSense 2.3_1 here in a CARP-cluster.

We are using rules with fqdn-aliases and those rules do not work.

When i look under diagnostics -> tables i see the tables filled with the 
correct IPs.

When I change the rule not to use the alias, but the IP instead, the rules 
works immediately.

 

It's really weired.

 

Does anyone have some idea for me ?

 

Regards,

martin !

___
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] firewall rules with fqdn-alias

[Martin Fuchs]

Hi !

 

We're using pfSense 2.3_1 here in a CARP-cluster.

We are using rules with fqdn-aliases and those rules do not work.

When i look under diagnostics -> tables i see the tables filled with the
correct IPs.

When I change the rule not to use the alias, but the IP instead, the rules
works immediately.

 

It's really weired.

 

Does anyone have some idea for me ?

 

Regards,

martin !

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