Date: Tue, 10 Jan 2006 12:49:53 -0800 From: Andrew Fremantle <freebsd@skyhawk.ca> To: Dennis Olvany <dennisolvany@gmail.com> Cc: freebsd-ipfw@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Advanced IPFW2 Forward rule problem / bug / misunderstanding Message-ID: <43C41DF1.3070305@skyhawk.ca> In-Reply-To: <43C3E684.5040204@gmail.com> References: <43C3896A.7090704@skyhawk.ca> <43C3E684.5040204@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis Olvany wrote:
>This should get you most of the way there or at least give you a good
>idea of what's required.
>
>
>
>
>>options IPFIREWALL_FORWARD_EXTENDED
>>
>>
>
>I'm pretty sure this will be required.
>
>
>
>
>>defaultrouter="24.85.92.1"
>>ifconfig_rl0="192.168.1.1"
>>ifconfig_vr0="142.179.109.xxx netmask 255.255.248.0"
>>ifconfig_vr1="216.232.85.xxx netmask 255.255.254.0"
>>ifconfig_rue0="24.85.9x.xxx netmask 255.255.252.0"
>>ifconfig_rue0_alias0="24.85.9x.xxx netmask 255.255.255.255"
>>
>>
>
>
>
>
>>Telus
>>ext1_ip="142.179.109.xxx" # IP Address
>>ext1_gw="142.179.104.254" # IP Gateway
>>ext2_ip="216.232.85.xxx" # IP Address
>>ext2_gw="216.232.84.254" # IP Gateway
>>
>>
>
>
>
>>Shaw Cable
>>shaw_ip="24.85.93.xxx" # IP Address
>>shaw_gw="24.85.92.1" # IP Gateway
>>srv2_ext="24.85.93.xxx" # External IP of server
>>
>>
>
>
>
>>INTERNAL
>>int_ip="192.168.1.1" # IP Address
>>
>>
>
>
>
>
>># And run our new NATd
>>/sbin/natd -log_ipfw_denied -i ${nat_in} -o ${nat_out} -s -m -u -n
>>${shaw} -punch_fw 36000:100 -redirect_port tcp ${ext1_srv}:22
>>${ext1_ip}:xxxx -redirect_port tcp ${ext1_srv}:53 ${ext1_ip}:53
>>-redirect_port tcp ${ext1_srv}:80 ${ext1_ip}:80 -redirect_port tcp
>>${ext1_srv}:443 ${ext1_ip}:443 -redirect_port udp ${ext1_srv}:53
>>${ext1_ip}:53 -redirect_port tcp ${ext2_srv}:80 ${ext2_ip}:80
>>-redirect_port tcp ${ext2_srv}:443 ${ext2_ip}:443 -redirect_port tcp
>>${srv1_int}:22 ${shaw_ip}:xxxx -redirect_port tcp ${srv1_int}:53
>>${shaw_ip}:53 -redirect_port udp ${srv1_int}:53 ${shaw_ip}:53
>>-redirect_port tcp ${srv1_int}:80 ${shaw_ip}:80 -redirect_port tcp
>>${srv1_int}:443 ${shaw_ip}:443 -redirect_port tcp ${srv2_int}:80
>>${srv2_ext}:80 -redirect_port tcp ${srv2_int}:443 ${srv2_ext}:443
>>
>>
>
>That's a hefty nat command. Let's simplfy by putting it in a file. I
>leave the port forwarding to you.
>
>/etc/rc.conf
>
>natd_enable="yes"
>natd_flags="-f /etc/natd.conf"
>
>/etc/natd.conf
>
>instance default
>interface vr0
>port 8668
>
>instance telus2
>interface vr1
>port 8669
>
>instance shaw1
>alias_address 24.85.93.xxx
>port 8670
>
>instance shaw2
>alias_address 24.85.93.xxx
>port 8671
>
>globalport 8672
>
>
>I see that your firewall is based on rc.firewall. Forget rc.firewall, it
>is junk. Base your firewall on this structure.
>
>1. Public Interface NAT Diversion
>
>2. check-state
>
>3. Public Interface Leak Prevention
> 3.1 deny egress from internal hosts
> 3.2 deny ingress to internal hosts
>
>4. Antispoof
> 4.1 allow via loopback interface
> 4.2 deny ingress from router
> 4.3 deny ingress from internal hosts via public interface
>
>5. Router
> 5.1 allow egress
> 5.2 deny egress
> 5.3 allow ingress
> 5.4 deny ingress
>
>6. Internal Hosts
> 6.1 allow egress
> 6.2 deny egress
> 6.3 allow ingress
> 6.4 deny ingress
>
>7. Default Deny
>
>
>/etc/rc.conf
>
>firewall_enable="yes"
>firewall_type="/etc/ipfw.rules"
>
>/etc/ipfw.rules
>
>-f flush
>
>add divert 8668 ip from any to any in via vr0
>add divert 8669 ip from any to any in via vr1
>add divert 8670 ip from any to 24.85.93.xxx in via rue0
>add divert 8671 ip from any to 24.85.93.xxx in via rue0
>#have never known the globalport to work on inbound
>add divert 8672 ip from any to any out via { vr0 or vr1 or rue0 }
>#not sure if that 'or' will work... may need to split it up
>
>check-state
>
>add deny ip from 192.168.1.1/24 to any via { vr0 or vr1 or rue0 }
>
>add allow ip from me to me via lo0 keep-state
>add deny ip from me to any in
>
>add allow ip from me to { me or 192.168.1.1/24 or 142.179.109.xxx/21 or
>216.232.85.xxx/23 or 24.85.9x.xxx/22 } keep-state
>add forward 142.179.104.254 ip from 142.179.109.xxx to any keep-state
>add forward 216.232.84.254 ip from 216.232.85.xxx to any keep-state
>add forward 24.85.92.1 ip from 24.85.9x.xxx to any keep-state
>add forward 24.85.92.1 ip from 24.85.9x.xxx to any keep-state
>add allow ip from me to any keep-state
>add deny ip from me to any
>add allow icmp from any to me icmptypes 3,4,8,11 keep-state
>add deny ip from any to me
>
>add allow ip from 192.168.1.1/24 to any keep-state
>add deny ip from 192.168.1.1/24 to any
>add allow icmp from any to 192.168.1.1/24 icmptypes 3,4,11 keep-state
>add deny ip from any to 192.168.1.1/24
>
>
Thank for the quick reply.
I just want to clarify a few things here.... Given that I only want
outbound NAT on one interface, is it really necessary to run four
instances of NATd? Can't one instance handle outbound NAT + inbound
sessions on all interfaces, as I have it setup? Also, you're using a
whole bunch of options and features here that are not documented on the
natd man page. I found a writeup by the author of these features, but
I'm not certain if that's in the -STABLE branch or not. (IE, will these
options work with a 6.0-RELEASE natd?)
Also, I'm not certain how your forward rules would work when mine do
not, as you're doing the same thing I did - NAT Translation, then
forward to the appropriate gateway. My experience is that forwarding
packets to the appropriate gateway *does* *not* *work*, as they all
leave via the default route's interface anyways.
I see your ipfw rules keeping state on NATd sessions, which I have
learned is not a good idea. Isn't it far better to let NATd handle state
on all NATd traffic, and just use ipfw to keep-state on
locally-generated sessions?
Still, a quick glance doesen't show me any reasons why your rules
*wouldn't* work, ( At least, no more reasons than my own rules don't
work) and it is drastically more compact than my own (Though I have an
easier time visualizing packet flow with my layout). I might give these
a shot in a couple of days (I don't have physical access to the machine
right now).
- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43C41DF1.3070305>