# nat in ipfw



## douglasfim (Mar 10, 2011)

Would like more information about *nat ipfw*. In the _handbook_ I only found information about *natd* and not *nat* "native" *ipfw*. I would like to know what the advantages and disadvantages of *natd* are. Just replaced a server *Slackware/Linux* for a server *FreeBSD* but I cannot configure the _firewall_ *"ipfw"*.

First I would like to configure *nat*. I recompiled the kernel with these settings:


```
options		IPFIREWALL
options		IPFIREWALL_VERBOSE
options		IPFIREWALL_VERBOSE_LIMIT=5
options		IPFIREWALL_DEFAULT_TO_ACCEPT
options		IPDIVERT
options		IPFIREWALL_NAT # Enable NAT
options		LIBALIAS # Needed for NAT
```

Use the PF is a good idea?

PF works well on FreeBSD? Like in OpenBSD?


----------



## Alt (Mar 10, 2011)

ipfw does not have "native" nat. You can use *natd* or *ng_nat* and pass packets to them using *divert*. Or as option is libalias but i dont think it can be called "native"...
// I used it long time ago, but now i do nat with PF. Its easier to setup and far more powerful


----------



## douglasfim (Mar 10, 2011)

mix *IPFW* and *PF* is good?


----------



## Alt (Mar 10, 2011)

Sure, no. Dont know will they work together at all.. Just describing for "just-nat" task you can be done in 10minutes =)
Do you have many rules in ipfw?


----------



## douglasfim (Mar 10, 2011)

I have no rule

I will create a _firewall_ from scratch


----------



## Alt (Mar 10, 2011)

Ok then, before work you should make 'political' decision which firewall you will use.. Maybe its better to google about this/compare them..
// I would select PF, regardless i know ipfw better..


----------



## douglasfim (Mar 10, 2011)

I tryed google but only got more confusing and preferred to ask here

I just need to do nat and filter ports

to enable *PF* just add that?


```
device pf
device pflog
device pfsync
```

need something else to enable the kernel?


----------



## Alt (Mar 10, 2011)

Related topic for this http://forums.freebsd.org/showthread.php?t=3725 (compiling pf to kernel - post #11).
You can do some tests without recompiling (loading pf with kldload), create some rules, test them etc, and recompile later


----------



## SirDice (Mar 10, 2011)

douglasfim said:
			
		

> I tryed google but only got more confusing and preferred to ask here


How about the handbook? 

30.4 The OpenBSD Packet Filter (PF) and ALTQ


----------



## DutchDaemon (Mar 10, 2011)

Alt said:
			
		

> ipfw does not have "native" nat. You can use *natd* or *ng_nat* and pass packets to them using *divert*. Or as option is libalias but i dont think it can be called "native"...



ipfw supports in-kernel NAT using the kernel version of libalias(3). The previous sentence was lifted from ipfw(8). Native / in-kernel, sounds 'local' enough to me.


----------



## DutchDaemon (Mar 10, 2011)

douglasfim said:
			
		

> mix *IPFW* and *PF* is good?



That is never a happy marriage, especially if you need to troubleshoot network problems. I'd say use PF. It's less 'entangled' than ipfw. A kernel module/option, and a config file, that's it.


----------



## kpa (Mar 10, 2011)

PfSense does use both because ipfw is needed to implement the captive portal in pfSense, it never mixes them on same interface though.


----------



## phoenix (Mar 10, 2011)

Alt said:
			
		

> ipfw does not have "native" nat.



Yes, it most certainly does have "native" nat.  Read through the man page for ipfw(8) on a FreeBSD 8.0 or newer system (it's even available on older systems, but is supposed to be faster/more stable on 8.0+).

Almost anything you can do with natd, you can do with nat keywords in IPFW.  There are a few limitations, but the tradeoff is much faster throughput/packet processing (ipfw nat packets never leave the kernel; natd packets are copied from the kernel to userland, mangled, then copied back into the kernel).


----------



## douglasfim (Mar 11, 2011)

the *PF* need *ALTQ* to run?

what's missing configuration to work?


```
device pf
device pflog
device pfsync
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build
```


----------



## DutchDaemon (Mar 11, 2011)

PF does not need ALTQ to run. You only need ALTQ if you want to use traffic priorisation/queueing. The fact that the *pfctl* command 'complains' about ALTQ is annoying, but not problematic.


----------



## douglasfim (Mar 16, 2011)

I'm using "trying" the *PF*

thanks


----------



## silicium (Apr 26, 2015)

phoenix said:


> Almost anything you can do with natd, you can do with nat keywords in IPFW.  There are a few limitations, but the tradeoff is much faster throughput/packet processing (ipfw nat packets never leave the kernel; natd packets are copied from the kernel to userland, mangled, then copied back into the kernel).



Is there only to replace the *divert natd* ruleset shown in IPFW handbook with *ipfw nat *rules as shown on ipfw() man page?
I am trying to build a home gateway, using net/mpd5 that also has NAT.
Is it better to use IPFW in-kernel NAT?


----------



## kpa (Apr 26, 2015)

silicium said:


> Is there only to replace the *divert natd* ruleset shown in IPFW handbook with *ipfw nat *rules as shown on ipfw() man page?
> I am trying to build a home gateway, using net/mpd5 that also has NAT.
> Is it better to use IPFW in-kernel NAT?



I would say it depends on the workload. For average home use you won't see a big difference between the user-space natd(8) and the in-kernel NAT in terms of performance.


----------

