Routing between interfaces? (FreeNAS as router)

[1.21gigawatts]

I have a particular situation in which I need to insert a freenas server in place of an existing router. We are replacing a Nitix box (later IBM Lotus Foundations) with FreeNAS, and the Nitix box also served as a router for the site. The PCs that are on the network use the Nitix box's inside address (10.10.10.1) as their default gateway AND as the address of the CIFS shares.

Security is not an issue, as the whole thing is behind a sonic wall firewall. If I am not able to configure FreeNAS to do this, I will have to touch the network configuration on over 50 computers, so this is kind of a big deal.

Any help with this would be greatly appreciated.

 

[cyberjock]

FreeNAS cannot act as a router. So you need to find an alternative.

 

[pirateghost]

Clearos or zentyal can do this. Or roll your own bsd box

Sent from my Nexus 5

 

[TheSmoker]

Standalone bsd is always a good choice. You can also try pfsense and/or monowall both based on bsd.

 

[1.21gigawatts]

I spent some time looking at alternatives. among them was ZFSguru which is pretty much a freebsd installation with some web interface gui for doing some small subset of the freenas things. I spent some time with that, figuring out how to do the routing I need.

ZFSguru is OK, but isn't nearly as integrated as freenas and not nearly as easy to adminster. Therefor, I'd still much rather do this project with freenas. So, I tried pretty much the exact same configuration steps in freenas, and lo and behold, it all works fine. What I did was the following:

In /etc/rc.conf, I added:

Code:

gateway_enable='YES'
defaultrouter='10.10.13.1’
pf_enable='YES'
pf_rules='/conf/base/etc/pf.conf'
natd_enable="YES"

in /etc/pf.conf, I added:

Code:

ext_if = "em1"
int_if = "em0"
localnet = $int_if:network
 
nat on $ext_if from $localnet to any -> ($ext_if)
pass from { lo0, $localnet } to any keep state

I actually made these changes to the appropriate files in /conf/base/etc so they would survive a reboot. This does exactly what I need - passing connections on em0 to em1. There is absolutely zero security in this setup, but it's not necessary as it all sits behind the company's sonic wall.

So now the question is, Is there anything really bad about doing this on freenas? This will save me from having to reconfigure the networking on over a hundred client computers, some of which are not readily accessible to me.

 

[cyberjock]

So now the question is, Is there anything really bad about doing this on freenas? This will save me from having to reconfigure the networking on over a hundred client computers, some of which are not readily accessible to me.

Well, does the manual say to do that? No.. hmm.. not the best idea.

Are you a FreeBSD master and can check out the code and make that determination for yourself? If not.. probably not something you should be doing for an OS that is sold as an appliance. But, you can do what you want. Just don't get upset when the whole thing topples over and you find things have gone much worse than you could have ever imagined. ;)

 

[1.21gigawatts]

Well, does the manual say to do that? No.. hmm.. not the best idea.

Are you a FreeBSD master and can check out the code and make that determination for yourself? If not.. probably not something you should be doing for an OS that is sold as an appliance. But, you can do what you want. Just don't get upset when the whole thing topples over and you find things have gone much worse than you could have ever imagined. ;)

I am not a FreeBSD "master" by anyone's definition, but I do know that the capabilities I have enabled here have long been a part of FreeBSD. I am not asking whether IXsystems can be held liable for a failure of the routing. I am asking whether said routing is likely to interfere with the other FreeNAS functions or vice versa.

ALL of the components involved in this simple routing are included in the standard FreeBSD release and in FreeNAS. All I am doing is making the appropriate changes to the config files to enable them. Should there be a FreeNAS problem down the road, it would be a simple matter to unconfigure the routing at least temporarily to allow testing on a "clean" FreeNAS system. Your answer on March 17 was

FreeNAS cannot act as a router.

I have since shown that FreeNAS can, indeed, act as a router. Now that I ask whether there's anything really bad about doing so, you say that if it's not in the manual, it's a bad idea simply because it's not in the manual. Perhaps I should rephrase the question: Does anyone know of a reason why, assuming it works OK now, this won't continue to work? And, assuming that there is no apparent interference between the routing function and the CIFS service and ZFS functionality, is there any reason why this is not likely to remain so?

 

[cyberjock]

I can make your face act as a hammer for a nail. Does that mean I *should* do it? Absolutely not. The same is true with whatever the **** you are doing. I don't care if it has existed in FreeBSD since 0.000.1 alpha.

So no, just because you "proved" that it works for your limited situation in no what whatsoever validates that it "can act as a router". You are jacking with an appliance OS. We don't condone, support, or put up with that kind of BS on this forum. If you don't intend to use FreeNAS within it's own limitations, there's 2 solutions. Either use FreeBSD(Which isn't an appliance based OS) or deal with your own problems outside of the forum.

But, coming in this forum and telling people to do things the developer even says is idiotic is only going to get you in serious trouble around here.

Just yesterday someone in IRC was trying to do something from the CLI using the FreeBSD wiki. He didn't get it when we told him that FreeNAS isn't FreeBSD and what was doing was going to give him a serious headache when he rebooted his box.

Perhaps I should rephrase the question: Does anyone know of a reason why, assuming it works OK now, this won't continue to work? And, assuming that there is no apparent interference between the routing function and the CIFS service and ZFS functionality, is there any reason why this is not likely to remain so?

We don't support, condone, hypothesize, etc for things that aren't officially sanctioned by the FreeNAS developers. PERIOD. If this isn't good enough for you, feel free to go to FreeBSD.

FreeNAS is an appliance-type OS. You want to deviate from that, you are on your own island and can deal with your own problems.. ON YOUR OWN.

You know, just yesterday I was discussing something with someone that involved locking the image in a way that you couldn't edit the OS without it making your FreeNAS install unbootable. Why was this being discussed? Because we're finding too many people blindly doing stupid stuff with FreeNAS, breaking FreeNAS, then blaming the project for their ignorance. So if we make FreeNAS not boot if it's been modified, you'll either use our OS in the way it was designed or you'll go elsewhere. Guess you're a good example for those people in favor of locking the image file, huh? Kind of sad that we have to resort to that kind of draconian rules to get people to not do things that are deemed as "stupid" or whatever, but I can already see that coming down the conveyor belt. :(

 

[jgreco]

I can make your face act as a hammer for a nail. :(

Just because someone did that to you, ... :)

But seriously if you are using natd you are NOT routing and you are in a seriously gray area.

To experiment with routing, undo what you've done and simply turn on net.inet.ip.forwarding

This is still a bad idea but is less likely to have unanticipated side effects.

 

[1.21gigawatts]

Just because someone did that to you, ... :)

But seriously if you are using natd you are NOT routing and you are in a seriously gray area.

To experiment with routing, undo what you've done and simply turn on net.inet.ip.forwarding

This is still a bad idea but is less likely to have unanticipated side effects.

What do you mean by "seriously gray area?" is that because of natd in particular or is it this whole project?

As it turns out, the natd line in rc.conf is not needed as pf has built in NAT. Also, gateway_enable='YES" in rc.conf is, to my understanding, the same as net.inet.ip.forwarding=1. The pf rules simply tell the gateway which packets to send where. Please correct me if I'm wrong. I understand that this is not a router in the usual sense, but it's doing what the nitix box it's replacing does as far as connecting the inside and outside networks and that serves the purpose that is required in this particular installation.

In no way am I suggesting that anyone else should do this. I'm simply asking what problems it may cause, other than my potential ostracization from this forum. I don't expect any help from anyone here on this particular subject and, as I said earlier, if there IS a problem that turns up, I can easily turn off this bit of configuration by simply commenting a few lines in rc.conf and rebooting.

 

[innocent_bystander]

I realize this is an old thread, but I found it very helpful and figured, I'd chime in.

First of, thanks to @1.21gigawatts. You've pointed me in the right direction.

I was in a similar situation, where I needed to replace an old Linux box running Samba, which was also routing between 2 subnets.

I am not sure how things were back in 2014 and I feel sorry for you for being viciously attacked by @cyberjock, but nowadays you can do it through the Web GUI.

There is a section called Tunables under the System category. All had to do is add a variable "gateway_enable", with value "YES" and type "rc.local". Rebooted and voila, my FreeNAS box is now routing! :)

Share and enjoy.

 

[garm]

Seriously this is such a bad idea..

 

[jgreco]

I realize this is an old thread, but I found it very helpful and figured, I'd chime in.

First of, thanks to @1.21gigawatts. You've pointed me in the right direction.

I was in a similar situation, where I needed to replace an old Linux box running Samba, which was also routing between 2 subnets.

I am not sure how things were back in 2014 and I feel sorry for you for being viciously attacked by @cyberjock, but nowadays you can do it through the Web GUI.

There is a section called Tunables under the System category. All had to do is add a variable "gateway_enable", with value "YES" and type "rc.local". Rebooted and voila, my FreeNAS box is now routing! :)

Share and enjoy.

We kindly ask that you not "share and enjoy." The design of the system doesn't anticipate that routing will be enabled, although -- speaking as someone who's done production-grade networks with SDN using FreeBSD for ~25 years -- setting ip.forwarding to enabled is unlikely to break much in FreeNAS. However, adding NAT to the mix may cause unanticipated issues such as when packets are rewritten prior to being processed by the FreeNAS userland. Cyberjock's response, while somewhat harsh in his usual style, is generally correct in that this isn't really something that your NAS appliance ought to be doing. If you need a router in your network, there are architecturally cleaner options available such as Ubiquiti's EdgeRouter-X (~$50) which can run traffic levels of almost 1Gbps unidirectional, or the EdgeRouter-Lite (~$100) that can run 1Gbps+ bidir, and is capable of full and proper NAT, firewalling, etc. at those speeds. For a little more cash you can also get some great pfSense appliances.

Because the developers of FreeNAS may feel free to change the FreeBSD environment and boot scripts at any time, if you are going to do this, I suggest that you do not use gateway_enable, and instead follow my previous instruction:

To experiment with routing, undo what you've done and simply turn on net.inet.ip.forwarding

This is still a bad idea but is less likely to have unanticipated side effects.

I picked those words very carefully to guide those interested in experimenting "against advice" with this. In certain cases, such as users who have 10Gbps ethernet without a switch, or certain other scenarios, it may make sense to use routing or bridging to accomplish a network implementation, but in all cases it is probably a mistake to rely on FreeBSD's rc scripts to set these up properly as the developers of FreeNAS have not put any effort into validating that this still works in the TrueOS/FreeNAS framework.

As a further hint, what I have outlined is something that has worked under every version of FreeNAS to date, whereas what you're suggesting only happens to work right now because of a happy accident, and didn't work under earlier versions of FreeNAS, and may not work under future versions.

 

[jgreco]

And for some reason it is capitalizing "IP" in the resulting text. The sysctl is lowercase-i-lowercase-p.

 

[innocent_bystander]

@jgreco I appreciate your detailed post and you are absolutely right -- in general it's a bad idear to mess around with the underlying OS. I don't even disagree with what @cyberjock was saying (outside of the way he was saying it).

It's just both the OP and myself had a bit of a unique situation and were willing to take the risk. And for me, being on a 10GbE network, "cheap" half 1Gb or even full 1Gb routers are out of the question. I'd rather have my fully redundant FreeNAS box do the routing.

As for sysctl net.inet.ip.forwarding=1 vs gateway_enable="YES" that's just "potahtoes" vs "poteitoes". Here is what setting gateway_enable="YES" does inside /etc/rc.d/routing:

Code:

if checkyesno gateway_enable; then
	ropts_init inet
	echo -n ' gateway=YES'
	${SYSCTL} net.inet.ip.forwarding=1 > /dev/null
else
	${SYSCTL} net.inet.ip.forwarding=0 > /dev/null
fi

This is from the FreeNAS github repo: https://github.com/freenas/os/blob/freenas/11-stable/etc/rc.d/routing#L344-L350

So, again thank you all for due warning, but for those of you not faint of heart, it *can* be done.

Lastly, regarding my "share and enjoy" comment, this is what I meant by it: http://hitchhikers.wikia.com/wiki/Share_and_Enjoy

So long and thanks for all the fish. :)

 

[jgreco]

As for sysctl net.inet.IP.forwarding=1 vs gateway_enable="YES" that's just "potahtoes" vs "poteitoes". Here is what setting gateway_enable="YES" does inside /etc/rc.d/routing:

Code:

if checkyesno gateway_enable; then
	ropts_init inet
	echo -n ' gateway=YES'
	${SYSCTL} net.inet.IP.forwarding=1 > /dev/null
else
	${SYSCTL} net.inet.IP.forwarding=0 > /dev/null
fi

I understand what gateway_enable does, and the point is that this is userland kerfuffery that's changed both within FreeBSD over the years, and also has not been present in FreeNAS, especially in the NanoBSD days, while net.inet.ip.forwarding has been the kernel level sysctl in FreeBSD since the day that this was exposed as a runtime-configurable option. Additionally, the FreeNAS UI has supported sysctl twiddling for a long time and that's expected to be pretty stable, while tweaking rc variables is not. Therefore, from both the FreeBSD and the FreeNAS side, gateway_enable is not really as good a choice as the direct sysctl.

If you want the information presented to be available and relevant for the long term, rather than just "what works today but did not a few years ago and also might not work next year," the sysctl itself is a much better target for modification.

 

[innocent_bystander]

@jgreco I hear you man. Thank you for sticking with me and taking your time to explain things. We need more mods like you. You have a good day sir.

 

[1.21gigawatts]

@jgreco I hear you man. Thank you for sticking with me and taking your time to explain things. We need more mods like you. You have a good day sir.

Just to close the loop on this: I did install the system with the rc.conf tweaks, and it ran fine for the six or so months that it was needed. Afterwards, we did a major network restructuring, and that functionality was no longer required, and we went back to a stone-stock configuration.

I have to say that I very much appreciate @jgreco's detailed explanation today. I wish that cyberjock would have answered that way instead of emptying his load of vitriol. Oh, well, no harm done (to me), but I wonder how many potential users are scared away from asking questions because of this.

Have a wonderful couple of weeks, I'm leaving for vacation in the Rockies.:)