Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

GUI *not* accessible without default gateway!

Joined
Sep 7, 2019
Messages
16
Thanks
0
#21
Thanx,

What I learned from today’s discussion is that my expectations of goal and abilities of FreeNAS VLAN’s was completely wrong :(

I think that, in this context, a VLAN can only be used to communicate with computers in the same subnet, otherwise it will be routed via FreeNAS default gateway. The FreeNAS VLAN definition, It is not just an endpoint of a VLAN, it is a routing gateway as well.

So the VLAN function is a point to point connection to another computer in the same subnet, but cannot be used to communicate with a computer with an IP-address not belonging to the VLAN-subnet, at least not without NAT.

That is a pity, but I understand Heracles its remark earlier in the discussion now. So I need to do NAT on pfSense or on the CRS317 (I do think pfSense, CRS has dramatically bad routing performance).

So my actual conclusions are:
- The Management VLAN gateway should also be the FreeNas default gateway.
- The other VLAN’s should not(!) carry any IP-address outside the VLAN’s subnet, so they will never generate (L3) routed traffic.
- To archive that, a routing device like e.g. pfSense should NAT traffic into the VLAN’s subnet ranges.

How to do that exactly, TBD.

Thanks Heracles! I really was hoping for more/other functionality, but I am very glad I understand now (I think)

Louis
 

Heracles

FreeNAS Guru
Joined
Feb 2, 2018
Messages
376
Thanks
108
#22
Hey Louis,

A VLAN is a Layer 2 concept and layer 2 only. It takes a single physique media and split it in multiple independent virtual media. Once that is done, everything that is in the same broadcast domain will see each other easily.

When you need to cross to different subnets, the host must know what the IP of the next hop is. If you have only a single default gateway as a router in that host, then the host has no choice but to use it. Should that only way out be on a different VLAN, the host will not mind and will try it that way,

That is called asymetric routing.

Because your next hop is a firewall, it will rejects the asymetric packet because it is not part of a known socket (not from that interface). For the firewall, to accept that would be the same as accepting IP Spoofing. So that packet will not make it pass the firewall.

So for your multi homing system works, the host must know about the potential next hop available in front of each of its own IP. Systems that are meant for that can have multiple default gateway. pfSense can and it is used when you have two redundant Internet Providers. PfSense can know and use the next hop on each of them. Also, because these next hops are routers and not firewall, asymetric routing will not be a problem.

Again, what we are talking about here has no relation at all with FreeNAS. We are talking about structure multi-path layer 3 networks. That is to be done by router first. Layer 3 switches are in the same category and can do it also. A firewall is not a good choice because it is way more strict than a router. A host, no matter FreeNAS or any other OS, is not meant at all for doing that.

In your FreeNAS, if you create VMs, you will have a separate IP stack in that sub operating system. It will be pretty easy to point that stack to a different interface, different IP, different subnet and different gateway.

But to do multi path IP routing on a host is asking for trouble, FreeNAS or any other.
 
Joined
Sep 7, 2019
Messages
16
Thanks
0
#23
Hi,

When I started this discussion, I did expect FreeNas to provide a couple of L2-endpoints.

I was expecting that those L2-endpoints would return not subnet related destinations, towards the VLAN gateway at the other end of the VLAN.

But the behavior turned out to be different. FreeNas does behave as L2 to Level-3 gateway and not as a (set of) L2-endpoint(s). With all kind of for me complicating consequences:
- I can not simply see FreeNas as one of the endpoints in a VLAN
- And it breaks my security architecture, because it allows data to be routed between VLAN’s, something an endpoint (like FreeNAS) in my concept should *never* allow (the host should in my model throw the packet away).

In line with your remark “If you have only a single default gateway as a router in that host, then the host has no choice but to use it.”, that is exactly why I was talking about a default gateway per VLAN much earlier in this topic and about VLAN specific routing keys later on.

But it is quite clear, that FreeNas is behaving different. It is routing between level-2 VLAN’s, something absolutely not fitting in my network model/design!

What I suggested in my previous male (NAT), is perhaps a solution for the physical routing. However since FreeNAS will be a (potential) bridge between the VLAN’s, it is not good for security reasons.

I really do not know yet how to archive the intended (physical)connectivity separation and for security intended segmentation. Perhaps/probable it is not even possible :(


Louis
 
Joined
Sep 7, 2019
Messages
16
Thanks
0
#24
For info,

I was just curieus what whould happen if I activated DHCP for one vlan. DHCP is 'in the end' providing the default gateway for the VLAN. But, I could hardly expect any thing else, it is not used. The stupid thing (freenas) thinks it has to do the routing itself :( (where IMHO freenas should never ever do level3 routing / provide a level3 gateway other than its own listener addres).

Of course I had expected this

Louis
 
Joined
Sep 7, 2019
Messages
16
Thanks
0
#25
The network limitations as I see them now, are really causing a problematic situation:


things to deal with
- I need a 1G-datalan next to the 10G-datalan, because the capacity of a combined lan would be limited to the speed of the 1G-lan
- the VLAN's are not secure, since FreeNAS provides L3-routing between those LAN's, and allows traffic to flow away from each VLAN via the default gateway.
- I need a management lan to create a FreeNas management IP, which can be filtered in the firewall
- I need to make sure that traffic is entering and leaving via the same VLAN, to prevent asymmetric routing.


(provisional) solution
The only way I see right now to archive this requirements is the following, complex setup
I need three VLAN's mngt, 1G-data and 10G-data (see above)

management
- the default gateway should be on the management LAN, since that is the only VLAN witch may send traffic to some external destinations.
- the management LAN is not secure, because data can be routed to that VLAN from the other VLAN's. However the management IP-address is fixed, so I can compensate for that. By taking two measures:
1) create an extra management LAN dedicated to the FreeNAS and
2) and a filter rule on pfSense to only allow traffic with the FreeNas management IP as source, to enter the real management VLAN

1G-and 10G datalans
- traffic should stay within that VLAN, so source addresses other than the VLAN's subnet range are not possible
- so I need to NAT the traffic towards that VLAN. That is 'complex and performance consuming' however I do not see another option
- that the data of this lan could be routed towards the dedicated freenas management lan and to the other data VLAN. However that is not severe since, I took precautions to protect the real management VLAN and the only reason to separate the 1G and 10G is dataspeed, security wise it is 'the same' VLAN.

I do not really like this solution, but I do not see another option.

Heracles if you or someone else see a better option, I would be glad to be advised.

Sincerely,


Louis
 

Heracles

FreeNAS Guru
Joined
Feb 2, 2018
Messages
376
Thanks
108
#26
Hey Louis,

First question is why do you bother about a 1Gig link when you have a 10G link ? It would be way easier to do just with the 10G one.

Second, there is no need for a separate VLAN for management. Management is performed over HTTPS or SSH. So just do filtering on the pfSense box to ensure the ones accessing FreeNAS over these ports are the authorized admins. Also, because management will not consume a significant bandwidth, no need to worry about that so again, do it over the 10G line.

For your understanding, it is not FreeNAS that is doing layer 3 routing. It is each and every single IP device configured to reach beyond its local subnet. A single NIC, single IP Windows desktop is doing routing whenever it needs to reach something beyond the local net. In this case, that system has only 1 way out. For that reason, there is no doubt, no ambiguity, no question : Go that single way. Here, you have 3. A Windows desktop with 3 NIC would face the same dilemna.

Here, I do have multiple NIC in my FreeNAS and there is no confusion :
4 of them are for iSCSI. These ones have their own IP ranges, no router, nothing to reach beyond the peer-to-peer connectivity and the rest of the network does not even know about these IPs.
1 is for the Prod and Management over the same NIC. Default GW is on that one.
Another I used for running VMs. As complete operating systems, these VM have their own IP stack, so do their own routing. Should I wish to plug one in one segment and another in a different segment, no problem and no confusion.
The last one is for the Dev side on my network. For that, I added a route in my FreeNAS saying that 172.16.1.0/24 is to be routed toward the Dev firewall instead of the default one.

At the end, a system in Dev call the Dev IP, is routed to destination and packets are back over the same path.
A system in Prod do the same, on the Prod side.
The dedicated bandwidth is provided on a third set of links.
Any VM do its own business wherever I plugged it.

Again, nothing wrong specific to FreeNAS here. This is just what the IP protocol is...

As for your 1G and 10G, you can always do NIC teaming (Link aggregation) to split your load on the two links. In that case, the pair of link will look as a single link and the teaming protocol will distribute the load on both. But because one of your link is 10x bigger than the other, no real benefit here.
 
Joined
Sep 7, 2019
Messages
16
Thanks
0
#27
Heracles,


I also feel that the cost of complexity is too high for what I try to archive.

1) the reason for the management lan is security
2) the reasons for the 1G are two:
- redundancy connections to two switches, note that the gs1920 is rock stable, where the change you have a problem if you/I touch the CRS is much higher. So nice to have connections left at that moment.
- need for a split lan's with different speed, the high speed network should be capable to run at full speed

If I only connect via one 10G VLAN, things would of course be lots, lots simpler. I could set the default gateway to point to that VLAN, problems gone!
- I lose the redundancy :(
- I can decouple high and low speed LAN at the router
- I have to do the management, in what is in principle less elegant way.

But I think I go for that compromise. "the cost" for the other solution is simply (far) to high.


Related to iSCSI, you use point to point connections. That has advantages (no/little overhead). Disadvantage it is point to point :(

Brings me to the multiple NIC's. You talk about that if that differs from multiple VLAN's. But why!? in my perception on logical level nothing changes!!??
- I think that if I place multiple NIC's in e.g. a windows computer, that will lead to the same 'routing problems' as we have been discussing here.
- same for FreeNAS. Mine has two NIC's (1G and 10G).

Apart from that, I have a practical limitation. From my 'switch room', physically there are only single connection. So VLAN’s are the only option.

From the network point of view I could create an extra VLAN between FreeNAS and my main PC. However that is windows-10 Pro. And I very much doubt, I did not investigate, if that is supporting iSCSI via a separate VLAN! (my N-Base-T adapter, can be configured to use (one) VLAN)


At this moment the PC is not even aware it uses a VLAN



Louis
 

Heracles

FreeNAS Guru
Joined
Feb 2, 2018
Messages
376
Thanks
108
#28
Hi again Louis,

1) the reason for the management lan is security
There are so many ways to secure an access. To force a different path at layer 3 is just one. Or you can think of your plan as by enforcing a different layer 1. In all cases, your pfSense can do that easily and is meant for that. Actually, your pfSense can do so much more.

Should you do packet filtering only, you can restrict the access at layer 3 / 4 : Permit TCP 22 and 443 only from the IP that are authorized to manage the FreeNAS.

Should you wish to do more, you can use HAProxy and do client side certificate authentication before forwarding the packets.

If you want to do even more, do a VPN to your pfSense, either IPSec or OpenVPN, and allow management only from there. The VPN will do authentication as strong as you wish and will do extra encryption. You can even use it to call back home when you are outside.

2) the reasons for the 1G are two:
- redundancy
Then again, go for Link Aggregation. Multipath at layer 3 MUST be done using routing. Multipath at layer 2 is not achieved by VLANs. VLANs separates things; it does not join them in a group of redundant things.

the high speed network should be capable to run at full speed
So by using only your single 10G link, you will have that easily.

Multiple physical NIC is not that different as multiple virtual NICs provided by VLANs. You just don't need to do tagging on either end of the link. But from your situation, it would not change much. Your problem is that you are trying to use VLANs for what they are not meant for (redundancy, multipath layer 3, ...)

Your security solution of a physical separate network is not that magical at all. Go with a VPN or HAProxy with client side authentication. That will be a million time more secure.

Your redundancy solution is based on wrong technology. What you need here is link aggregation (LACP) and not VLANs.

Your hardware solution is not well fitted for redundancy because one half is only 10% of the second half. Such highly unbalanced redundancy does not worth the trouble of configuring it.

With your actual setup, a single 10G link secured by pfSense is what you can achieve and would be very good.
To add redundancy, first get yourself a second 10G link.
Once you have it, do LACP between the 2 links and the pfSense.

If you are really mad about getting a separate network for management, you will need a physical connection from to that management interface to the management station. Should that station be allowed to do Internet and other stuff, it will bypass your pfSense, creating a major security gap in your architecture instead of increasing its security.

Honestly, I really think that your original plan was far to be optimal...
 
Joined
Sep 7, 2019
Messages
16
Thanks
0
#29
Hi Heracles,

I agree with you that VPN's etc. are more secure than VLAN's. But this an InHome network. I am not transferring data between two locations via the internet. I certainly would use an encrypted protocol in that case.

Be aware that my original plan was intended to separate InHome data streams, including guests, IoT like equipment (TV's etc) and perhaps computers carrying viruses but that is it! Its years back that I scanned a virus on one of my kids computers)

I was expecting that FreeNas was providing Level2/3 endpoints, which turned out to be quite wrong, making an easy solution a very complex one!
(I still think that L3 routing on an “endpoint”, and I regard FreeNas is one, as very insecure).

The reason was also that I changed the core of my network from 1G to 10G. And note that using the old 1G core switch for redundancy, is not optimal, but it is for free :)

Whatever, given the situation, I decide to choose for a very simple solution:
- Ony the 10G-VLAN to FreeNas
- Gateway from 1G PC-lan and 10G-PC-lan via/on PF-sense
- heavy PW and https on FreeNas GUI


Related to data transfer methods, I did some transfer tests with a 23,7 GB-file:
- iSCSI 8.2 min (transfer speed varies enormously)
- SFTP 8,2 min (near constant transfer speed)
- SMB 2,3 min (near constant transfer speed)
Using IPV6 in state of IPV4 leads to a somewhat higher transfer speed (~10%)

In the first two situation, iSCSI and SFPT, the CPU in the NAS seems to be the bottle neck (Intel(R) Pentium(R) CPU G4560 @ 3.50GHz (4 cores) 16 GB-ram. Note from the graphs I think that that only one out of four CPU’s is really, is busy.

I think that the SMB result, is for a large part due to the HD speed, however also there, only one CPU loaded and probably for about 80%. So also there only faster disk will not really spead up thinks.

All test via same VLAN's and via pfSense (actual speed, a bit below 2GBit, is no problem at all for my pfSense system).

Related to transfer method, I will be using SMB at least locally. By far the fastest !!


Since I think that this is the end of this thread, I would like to thank you and Elliot for the support !! Thanks !!

Sincerely,


Louis

[LvB1]
 
Top