On Monday 06 January 2003 11:52 am, Shook, Tim - AES wrote:
> Hello,
> I'm currently trying something rather unique with IPtables
> and need an opinion. I'm trying to forward and manipulate a packet
> with the following ip address:
>
> Source 192.0.0.1
>
> Destination 192.0.0.2
>
> If the MAC addresses on these are standard, manufacturer assigned
> addresses, everything works fine. If I manipulate the MACs with
> ifconfig and set them to ALMOST any other MAC, everything works fine,
> however when I set the MAC to a layer 2 broadcast (FF:FF:FF:FF:FF:FF),
> IPTables stops forwarding the packet.
>
> Now, the question is:
>
> Where is this packet being trapped and dropped? Is it in the kernel
> (routing)? Or is IPtables dropping it? Is the Ethernet card dropping
> it?
Try adding a LOG rule as the first rule in each and every chain. The
following example is extracted from my own firewall script, where I call
"service firewall xlog" to enable 'extreme logging', then "service
firewall xlogx" to disable it, and those script parameters trigger the
following functions:
# add_full_logging() enables extreme logging, ALL TRAFFIC
add_full_logging(){
$IPTABLES -t filter -I INPUT 1 -j LOG --log-prefix "IPT:XL-FILT-IN:"
$IPTABLES -t filter -I OUTPUT 1 -j LOG --log-prefix "IPT:XL-FILT-OUT:"
$IPTABLES -t filter -I FORWARD 1 -j LOG --log-prefix "IPT:XL-FILT-FWD:"
$IPTABLES -t nat -I OUTPUT 1 -j LOG --log-prefix "IPT:XL-NAT-OUT:"
$IPTABLES -t nat -I PREROUTING 1 -j LOG --log-prefix "IPT:XL-NAT-PRE:"
$IPTABLES -t nat -I POSTROUTING 1 -j LOG --log-prefix "IPT:XL-NAT-POST:"
$IPTABLES -t mangle -I INPUT 1 -j LOG --log-prefix "IPT:XL-MANG-IN:"
$IPTABLES -t mangle -I OUTPUT 1 -j LOG --log-prefix "IPT:XL-MANG-OUT:"
$IPTABLES -t mangle -I PREROUTING 1 -j LOG --log-prefix
"IPT:XL-MANG-PRE:"
$IPTABLES -t mangle -I POSTROUTING 1 -j LOG --log-prefix
"IPT:XL-MANG-POST:"
$IPTABLES -t mangle -I FORWARD 1 -j LOG --log-prefix "IPT:XL-MANG-FWD:"
}
end_full_logging(){
$IPTABLES -t filter -D INPUT -j LOG --log-prefix "IPT:XL-FILT-IN:"
$IPTABLES -t filter -D OUTPUT -j LOG --log-prefix "IPT:XL-FILT-OUT:"
$IPTABLES -t filter -D FORWARD -j LOG --log-prefix "IPT:XL-FILT-FWD:"
$IPTABLES -t nat -D OUTPUT -j LOG --log-prefix "IPT:XL-NAT-OUT:"
$IPTABLES -t nat -D PREROUTING -j LOG --log-prefix "IPT:XL-NAT-PRE:"
$IPTABLES -t nat -D POSTROUTING -j LOG --log-prefix "IPT:XL-NAT-POST:"
$IPTABLES -t mangle -D INPUT -j LOG --log-prefix "IPT:XL-MANG-IN:"
$IPTABLES -t mangle -D OUTPUT -j LOG --log-prefix "IPT:XL-MANG-OUT:"
$IPTABLES -t mangle -D PREROUTING -j LOG --log-prefix "IPT:XL-MANG-PRE:"
$IPTABLES -t mangle -D POSTROUTING -j LOG --log-prefix
"IPT:XL-MANG-POST:"
$IPTABLES -t mangle -D FORWARD -j LOG --log-prefix "IPT:XL-MANG-FWD:"
}
Once you log a few attempts to connect, shut the logging off and examine
the logfile results. 2-3 pings is sufficient, but if you have other
traffic at the same time then add "-p icmp" to each rule to avoid
excess. You should be able to (ordinarily) follow a packet as it hits
manglePRE, natPRE, then either mangleIN and filterIN, or mangleFORWARD,
filterFORWARD, natPOST, and finally manglePOST. If you see absolutely
nothing then it's never reaching the firewall rules at all. Otherwise
you should be able to follow it through the chains and see which two it
disappears between. If it vanishes after natPRE then it is being
dropped in the routing decision.
> I'm going to try to build a test version of the latest iptables source
> and put some debug stuff in to find out if iptables is seeing this
> packet, however I was hoping someone well educated with IPtables might
> enlighten me as too what is happening here.
To just 'find out if iptables is seeing it' all you should need are the
log rules above.
j
> NOTE: I am fully aware of the bizarre setup that I am using and the
> MAC layer address issue. This is not standard. I've been tasked to
> fix a custom software broken IP problem with a device that will mangle
> packets for me and retransmit them as if they were not broken. Linux
> is of course the obvious choice and iptables does 99.9999 % of what I
> need it to do. It works fine and does well up to this broadcast MAC.
> I just can't get passed this last hurdle.
>
> Any ideas or suggestions would be helpful
>
> Thanks
>
> Tim
> ************************************
> If this email is not intended for you, or you are not responsible for
> the delivery of this message to the addressee, please note that this
> message may contain ITT Privileged/Proprietary Information. In such a
> case, you may not copy or deliver this message to anyone. You should
> destroy this message and kindly notify the sender by reply email.
> Information contained in this message that does not relate to the
> business of ITT is neither endorsed by nor attributable to ITT.
> ************************************
