a Nat option would be helpful for gateway systems

[KarlGoetz]

It would be great if ufw could grow a 'nat' option. it would remove the need to manually edit configuration files to setup forwarding.
I sort of imagine it could be used like this -

ufw [--dry-run] [delete] nat [from ADDRESS RANGE] [to INTERFACE]
or
ufw [--dry-run] [delete] nat [from ADDRESS RANGE] [to ADDRESS RANGE]

EG:
ufw nat 172.17.172.0/20 eth0
ufw nat enable

or
ufw nat 172.17.172.0/20 10.10.10.0/14
ufw nat enable

hope the ideas not to crazy.

[KarlGoetz (kgoetz)]

Didnt add:
If it were implemented it could be added to here perhaps: (allow|deny|limit|nat)

       ufw [--dry-run] [delete] allow|deny|limit [proto protocol] [from ADDRESS [port PORT]] [to ADDRESS [port PORT]]

[Jamie Strandboge (jdstrand)]

Thank you for using ufw and issuing the bug. The idea is not crazy at all and I often envisioned ufw doing this. However, I am not sure when or if this functionality will be added, because the main focus is host-based firewalls. This may be added in the future, but it is important that ufw's interface not become 'complicated' and simply a different (but equally complex) syntax to iptables. For example, while you and I clearly know what 'nat' is, the average ufw user may not (and there is the whole issue of masquerading vs not masquerading).

I believe it should be possible, but it has to be carefully thought out.

[KarlGoetz (kgoetz)]

On Fri, 2008-07-11 at 13:31 +0000, Jamie Strandboge wrote:
> Thank you for using ufw and issuing the bug. The idea is not crazy at
> all and I often envisioned ufw doing this. However, I am not sure when
> or if this functionality will be added, because the main focus is host-
> based firewalls. This may be added in the future, but it is important
> that ufw's interface not become 'complicated' and simply a different
> (but equally complex) syntax to iptables. For example, while you and I

I understand - i partially suspected this was why i hadnt seen it on the
TODO list.

> clearly know what 'nat' is, the average ufw user may not (and there is
> the whole issue of masquerading vs not masquerading).
>
> I believe it should be possible, but it has to be carefully thought out.
>
> ** Changed in: ufw
> Importance: Undecided => Wishlist
> Status: New => Confirmed
>
--
Karl Goetz <email address hidden>

[David Burgess (apt-get)]

I'd like to add my vote to adding NAT options to ufw. I ran a debian gateway/firewall for a while and webmin was a lifesaver. Without webmin in ubuntu I find myself spending too much time trying to make my iptables config working.

db

[John Dong (jdong)]

What a general user considers a "NAT" (i.e. more like a masquerading router / connection sharing solution) is more than just a set of iptables rules -- with the spirit of UFW if one expects a one-command NAT then we have to set up a DHCP server and DNS cache too. I think this should be beyond ufw's scope and maybe some "uncomplicated home router" tool's job :)

[slavik (gslavik)]

What about adding a "via" keyword.

I only recently found ufw and it is awesome. I learned how to use ipfw on FreeBSD and was somewhat surprised that there wasn't something similar.

Below is what ipfw rules look like to do natting
# ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state
# ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state
# ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state

Regards,
Slavik

[Jake (jacob-m-robinson)]

This is number one on my wishlist! I for one need static 1:1 nats, but masquerade would be handy too...

ufw [--dry-run] [delete] nat [mask] [from ADDRESS] [to ADDRESS|PORT]

[enedene (enedene)]

One more vote for this important feature.

[airtonix (airtonix-gmail)]

Isn't the problem of not including mean that those who want Network Address Translation will then have to stop using UFW and use some other firewall that does provide NAT?

[airtonix (airtonix-gmail)]

Ok let me simplify this :

1. i create a python script to insert the NAT rules into /etc/ufw/before.rules
2. i create a pyGTK gui to manipulate this script
3. user profits

will UFW and therefore GUFW undo those NAT rules i inserted into /etc/ufw/before.rules

Ideally you would be better off just implementing a /etc/ufw/nat.rules file instead of making us sed or grep through another file which changes all the time.

[Jamie Strandboge (jdstrand)]

airtonix,

Regarding not using ufw for NAT: you can use ufw for NAT, it is just that the cli command does not expose that functionality. In other words, the ufw framework is designed so you can add iptables-restore style commands directly to /etc/ufw/*.rules. See 'man ufw-framework' for details. Adding support for NAT is planned.

/etc/ufw/before.rules should not be touched by the ufw command. This is for the admin to use and modify as desired. The ufw command edits files in /lib/ufw/user*.rules (or /var/lib/ufw/user*rules in older releases).

[Anders Jackson (anders-jackson)]

There is better tools for a NAT firewall/router, like shorewall.
This is a great tool for managing firewalls on clients, which should/could not handle NAT. If there are need for NAT, you can read up on the good instructions on Ubuntu wiki where you easily can manage NAT and all that mess in one place.

One MIGHT want to move rules in /etc/ufw/before.rules into /etc/ufw/nat.rules (or something). Then it would be as easy as to just drop a new file int /etc/ufw to get NAT. But NAT is not fire wall, so it should not be a use case for ufw, I guess.

And if you can manage NAT, dhcpd and dns, you can manage to change one file with vi/emacs/sed/whatever on one machine.

No, I think there are other places where we need enhance ufw.

[Stephen T Satchell (satch89521)]

# Implementation suggestion for this feature request:
#
# Define the following parameters in /etc/ufw/ufw.conf:
# NAT_IF=<public interface device name, like 'eth0'>
# NAT_PROTOCOLS=tcp/1024:65535,udp/1024:65535,icmp,47,50,51
#
# Derive
# NAT_IP = first IPv4 address of device
# from `ip address show NAT`, filter IP address
# /inet ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\//
#
# NAT_PROTOCOLS allows adding or removing IP protocols from the
# NAT list. This list works with Microsoft, Cisco VPN, and other
# less common networking services.
# (gre used by VPN, Ciso, IPset, PPTP, and more)
# (esp used by IPSec VPN)
# (ah used by IPset VPN)
# For advanced users, other protocols can be added to or removed
# from this list, and TCP/UDP port ranges can be adjusted.
#
# The output of the default list would then look like this:

/sbin/iptables -t nat -A POSTROUTING -o NAT_IF -p tcp -j SNAT --to-source NAT_IP:1024-65535
/sbin/iptables -t nat -A POSTROUTING -o NAT_IF -p udp -j SNAT --to-source NAT_IP:1024-65535
/sbin/iptables -t nat -A POSTROUTING -o NAT_IF -p icmp -j SNAT --to-source NAT_IP
/sbin/iptables -t nat -A POSTROUTING -o NAT_IF -p 47 -j SNAT --to-source NAT_IP #gre
/sbin/iptables -t nat -A POSTROUTING -o NAT_IF -p 50 -j SNAT --to-source NAT_IP #esp
/sbin/iptables -t nat -A POSTROUTING -o NAT_IF -p 51 -j SNAT --to-source NAT_IP #ah

REASON: It simplifies the programming if the code doesn't have to deduce the "correct" interface for the public Internet. Designed so that the code is a simple add-in to the IPTABLES command generation.