Linux – iptables is occasionally logging MAC addresses. Why

iptableslinuxloggingmac address

I have logging enabled on specific iptables packet drops. The rules I'm using are IP/port related only and this is what I can easily see in the logs, however occasionally I do get MAC address information logged as well. Like:

"….OUT=eth1 IN= MAC=00:26:a9:7b:c9:30:00:17:0f:ac:6a:80:08:00"…

These mac-addresses related logs are sporadic.

What I have noticed:

these dropped/mac-logged communication are always inbound
the source mac-address logged is the one of my default-gateway (Service Provider), although the source IPs are different.
the destination mac (obvious but just to confirm) is the one of my interface

What I'm trying to understand:

what is the iptables logic when deciding to capture in the logs "MAC addresses + IP/port" instead of "IP/port" only.

Best Answer

The MAC information is only logged for devices on your local network. It is actually a hex dump of the ethernet MAC header and consists of the source MAC address (00:26:a9:7b:c9:30), destination MAC address (00:17:0f:ac:6a:80) and ethernet frame type (08:00).

Related Solutions

Linux – Port forward + openVPN + iptables

Try these rules on your gateway:

-A PREROUTING -i $VPN_INTERFACE -p tcp -m tcp --dport 80 -j DNAT --to-destination $INTERNAL_IP_DESTINATION:80
-A POSTROUTING -o $VPN_INTERFACE -j SNAT --to-source $VPN_IP_OF_SERVER
-A POSTROUTING -o $LAN_INTERFACE -j SNAT --to-source $LAN_IP_OF_SERVER

1st. one makes the port forwarding.
2nd. makes the source nat so every packet comming out of the VPN uses the server IP
3rd. makes the packets forwarded to the internal IP, have the soure nat of the server lan ip

Iptables ESTABLISHED,RELATED chain problems

Netfilter has dropped the connection from the state table. One of the timeouts in /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_* has expired. I'm guessing it is nf_conntrack_tcp_timeout_last_ack.

Here is a scenario: Your web server sends a final packet with some data and fin set. The client goes comatose for 30 seconds. Netfilter removes the entry from the state table. The client wakes up and sends a fin ack that is not part of a tracked connection anymore.

I see this all the time on web servers. It is client problem.

If you want to verify that you could record the state table (/proc/net/nf_conntrack) and correlate that with the firewall log.

Edit: I had the direction reversed but the concept applies. In this case his server is making outgoing https connections so it is actually the client and the remote web server may be slow to respond.

The rule

/sbin/iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT

has nothing to do with it. It is about DST port 443 and this is SPT 443.

Best Answer

Related Solutions

Linux – Port forward + openVPN + iptables

Iptables ESTABLISHED,RELATED chain problems

Related Topic