Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Jul 2019 09:57:57 -0700
From:      Yuri <yuri@rawbw.com>
To:        Michael Sierchio <kudzu@tenebras.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: How to set up ipfw(8) NAT between an alias and the main IP address, when the alias is in another network?
Message-ID:  <cba9ffdb-ac5e-35ef-c304-91803e575f08@rawbw.com>
In-Reply-To: <CAHu1Y711JVCo2koCivAbduFp42ddL1eHfTdNBK6qqPeGwGUftw@mail.gmail.com>
References:  <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> <CAHu1Y711JVCo2koCivAbduFp42ddL1eHfTdNBK6qqPeGwGUftw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-07-08 10:17, Michael Sierchio wrote:
> NAT is already maintaining state – it is possible to combine stateful rules
> and NAT, but don't. ;-)
>
> Are you really proposing to NAT twice, or is 192.168.1.2 a phony address
> for the purposes of discussion here?
>
> In any case, consider something like the following:
>
> #!/bin/sh
>
> fw="/sbin/ipfw -q"
> sysctl net.inet.ip.fw.one_pass=0
>
> IP_JAIL="192.168.100.2"
> IP_EXIF="192.168.1.2"
>
> OIF="sk0"
>
> ################################################################################
> # If 192.168.1.2 is really your interface address, you'll be nat'ing twice
> # on the way to the internet, which is ugly. You don't need the *unreg_only*
> # directive if you only have  RFC1918 addresses anyway. You should clarify
> # if this is the case. *reset* kills all active nat sessions if you run this
> # script again.
>
> $fw flush
>
> $fw nat 1 config \
>      redirect_addr ${IP_EXIF} ${IP_JAIL} \
>      redirect_addr ${IP_JAIL} ${IP_EXIF} \
>      if ${OIF} unreg_only reset
>
> ################################################################################
> # separate in and out as a matter of habit - don't mention protocol in nat
> # statement, do this in subsequent rules
>
> $fw add 01000 nat 1 ip from any to any in recv ${OIF}
>
> # check-state isn't needed, really, since it gets performed at the next
> # rule that mentions state
>
> #$#$#$#$# $fw add 01500 check-state
>
> # these will match traffic to/from external IP and not jail
>
> $fw add 02000 allow tcp  from ${IP_EXIF} to any out setup keep-state
> $fw add 02010 allow udp  from ${IP_EXIF} to any out keep-state
> $fw add 02020 allow icmp from ${IP_EXIF} to any out keep-state
>
> ################################################################################
> # Why is this safe? because it will only match NAT return packets.
> # It only permits traffic to your jail in this case. Also, for TCP to
> # function properly, to need to accept ICMP error messages, esp. need-frag
>
> $fw add 02000 allow ip from any to ${IP_JAIL}
>
> ################################################################################
> # outbound packets pass through nat
>
> $fw add 03000 nat 1 ip from any to any out xmit ${OIF}
>
> ################################################################################
> # if your default rule (65535) is DENY, you need something like this. This
> will
> # match only NAT'd traffic
>
> $fw add 50000 allow ip from any to any out xmit ${OIF}


Thanks for this script, Michael.


I tried it on both my host system and in the virtual machine, with a 
different set of addresses, but it blocks outgoing connections from the 
original system, while allowing connections from jail. I think that the 
reason is that NAT translates the return packets that are destined for 
the original system, as if they were going into the jail. I'm also not 
looking for a script altering the whole firewall table, I only need to 
add particular rules for the jail without changing existing rules.


The precise definition of what I need is this: jail IP is in a different 
net. All outgoing traffic from jail has to be natted when its 
destination is outside. Return traffic should be natted only when it 
corresponds to the sent traffic from jail. Host connections should not 
be affected by NAT. I think that this is possible, because firewalls are 
generally able to match incoming packets to the outgoing connections.


Yuri





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cba9ffdb-ac5e-35ef-c304-91803e575f08>