I had trouble with that, too, but I have used ipportfw to do this
kind of redirection, like
ipportfw -A -t outside-ip/80 -R inside-ip/80
There's new syntax with ipmasqadm, but it's pretty close to that.
I missed the beginning of this thread, so I hope I'm not missing your
point.
Charlie Shoemaker
> Subject: Re: [masq] Limitation problem....
>
> >But I can't understand half of the rules....
> >And this is really boring for me...
>
> Yeah.. it is pretty dry stuff. I know where you are coming
> from.
>
>
>
> >> /sbin/ipfwadm -I -a accept -b -P tcp -S 192.168.0.7/32 80 -D 0.0.0.0/0
> >> 1024:65535
> >That did not work much more....
>
> Try pulling the "-b" option out and try again.
>
>
>
> >Hummmm... Where I can find a doc about
> >the difference between the different list,
> >and in particular -F -I and -O.
> >Or can you explain us (for all masq reader) clearly what is their
> >aim???
>
> Well, you could read the ipfwadm man page but its pretty ugly.
>
>
> How is this? I just added it to my TrinityOS doc so if you
> have anything to add to make it clearer, etc.. lemmie know.
>
> --
>
> Think of a IPFWADM or IPCHAINS ruleset like the following:
>
> - All interfaces (any network cards, the localhost
> interface, etc) on a Linux box have INPUT, OUTPUT,
> and FORWARD rules.
>
> For example:
>
>
> - Say you have a packet from the Internet that
> wants to reach your Linux box.
>
> 1) The packet is sent from the remote computer
> on the Internet
>
> 2) The packet is received on the INPUT rule on
> the -External NIC card- of the Linux box
>
> 3) If the packet is matched to allow the packet
> through:
>
> Some matching criteria can include:
> - source IP address
> - traffic on TCP and specific port
> - traffic on TCP and specific port
> - destination IP address
> - etc
>
> then let the packet though. If not matched,
> its either REJECTED or DENIED. You can
> also log the fact that this packet was
> killed.
>
> 4) If passed, the packet then goes to the Linux
> box to be processed. Once the reply
> traffic is calculated by TELNET, etc, this
> output traffic is then sent to the OUTPUT
> filter.
>
> 5) If the packet is matched to allow the packet
> through, its let though. (see #3 above).
> If not matched, its either REJECTED or
> DENIED. You can also log the fact that
> this packet was killed.
>
> 6) If passed, the packet leaves the Linux box to go
> over the Internet connection destined to that
> remote computer.
>
> NOTE: As you've seen, I've left out the FORWARD
> rule. Basically, all that the FORWARD rule
> does is if the packet is matched to be
> allowed, the packet is FORWARDed directly
> to some other interface. Once forwarded,
> the receiving interface will still try to
> match this packet against it's INPUT rule.
>
>
> +------------------------------+
> | Linux TCP/IP stack |
> | |
> +--->| Input: Output: |
> | +------------------------------+
> | |
> | |
> +----------- + | +------------+ |
> | Input | | | Output | |
> | Rule | | | Rule | |
> | | | | | |
> +-IN--->| P a s s ? |---+ +---| P a s s ? |<---+
> | | or | | | or |
> ^ |Deny/Reject?| | |Deny/Reject?|
> -------- +------------+ | +------------+
> Send | | |
> -------- +--> Dump packet | +--> Dump packet
> Remote (possibly log it) | (possibly log it)
> Internet |
> site |
> -------- |
> Receive <--------------------------+
> --------
>
>
> --David
> .----------------------------------------------------------------------------.
> | David A. Ranch - Linux/Networking/PC hardware [EMAIL PROTECTED] |
> !---- ----!
> `----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch -----'
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> For daily digest info, email [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
