[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Advanced IPFW2 Forward rule problem / bug / misunderstanding
Andrew Fremantle wrote:
> 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?
I'm sure you'll need one instance for each public IP from which you wish
to originate traffic.
> 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?)
Yes. I use these features with 6.0-release.
> 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.
Have a look at the routing table and examine the route to the forwarding
destination. Traffic should follow the most specific route to the
destination and transmit via the specified interface. You can always use
static routes to achieve this.
> 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?
Dynamic rules are perfectly acceptable with natd, with the exception of
incoming connections. Do not keep-state on those.
> 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).
It's all about the nat configuration and I think using globalport is the
only way you're going to get those outbound translations right. I
recently created a client load-sharing nat using a very similar
configuration. Concerning the shortcomings of your rules, I have no
idea. I didn't even attempt to decipher them.
/sbin/natd -i 8667 -o 8669 -n rue0
Let's have a look at your nat configuration. I don't know what you're
trying to achieve by using different in/out ports. You've set the
interface as rue0, so the nat is going to alias packets using an IP
associated with that interface. If you want to alias different addresses
on the same interface, you'll need to use alias_address instead of
interface and run multiple instances.
