* iptables not responding to packets destined for subinterface
@ 2004-10-31 5:12 Support Team
2004-11-01 13:03 ` Pete Toscano
0 siblings, 1 reply; 6+ messages in thread
From: Support Team @ 2004-10-31 5:12 UTC (permalink / raw)
To: netfilter
My public interface has serveral IP address aliases. Only the primary IP
address responds to traffic (ip, imcp, et al). I inserted a log statement
at the top of each table and found that the packets destined for the virtual
addresses never made it to any table. However, according to tcpdump, I
confirmed that the packets did get picked up by the kernel on the secondary
address. I guess they are just not passed to iptables. Obviously, the
packet was never replied to (icmp) or acknowledged (ip) by the process.
How can I get iptables to respond to the packets on the secondary
interfaces? Or, how can I get the kernel to pass the packets to iptables?
I understand that when the packet hits the chain, all I have to do is create
a rule with the primary interface and use the IP address to distinguish the
packets of different virtual addresses.
If you are looking for more detail, see the email I sent on Sun, 24 Oct, at
9:28 p.m. (GMT -6).
Thanks for your help!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iptables not responding to packets destined for subinterface
2004-10-31 5:12 iptables not responding to packets destined for subinterface Support Team
@ 2004-11-01 13:03 ` Pete Toscano
0 siblings, 0 replies; 6+ messages in thread
From: Pete Toscano @ 2004-11-01 13:03 UTC (permalink / raw)
To: netfilter
Support Team wrote:
> My public interface has serveral IP address aliases. Only the primary IP
> address responds to traffic (ip, imcp, et al). I inserted a log statement
> at the top of each table and found that the packets destined for the virtual
> addresses never made it to any table. However, according to tcpdump, I
> confirmed that the packets did get picked up by the kernel on the secondary
> address. I guess they are just not passed to iptables.
What options did you use for tcpdump? I say this because if you were
doing something like this:
tcpdump -ni <pub_interface> host <aliased_ip>
Then that'll put your interface into promisc mode, where tcpdump will
see them, but if the problem's as I suspect, the dest Ethernet MAC
address is wrong.
> Obviously, the
> packet was never replied to (icmp) or acknowledged (ip) by the process.
I do something very similar on a few boxes and this works fine unless
provisions are made to handle things differently. Pings return ICMP
Echo Replies and IP packets that aren't explicitly DNATed are handled by
the NAT box. (You might want to have a default "drop all" rule for
every aliased IP address to make sure you aren't leaking public access
to your NAT box; I think setting the policy of the PREROUTING chain to
DROP might do this too, but I haven't checked this. You also might want
to double-check that the other services on your NAT box aren't binding
to your public interface unless you specifically want to make them
available.)
I have a new IP address to alias and DNAT (sometimes SNAT too, but I
won't get into that here). I add the alias to my public interface, then
add the specific forwarding rules to the PREROUTING chain in the nat
table. Something like this:
iptables -t nat -A PREROUTING -i eth0 -p tcp -d <new_pub_ip> --dport 80
-j DNAT --to-destination <some_private_ip>:<some_internal_port>
In this case, eth0 is my public interface and I'm only interested in
DNATing TCP/80 traffic.
This used to be all I did to set up my DNATing, but things were kind of
flaky for a while if I was moving the public IP address from a different
interface on the pubic Ethernet segment (such as swapping out the NAT
box).
I forgot that the router I was connected to would cache ARP responses
and since the ones specific to the IP address I was moving hadn't
expired, the router was still sending out packets to my newly aliased IP
address using the old MAC address. Obviously, since the Ethernet
interface that the IP address was moved to didn't have that old MAC
address, it just dropped and packets sent to it, not even looking beyond
the Ethernet frame.
When I'd run tcpdump as shown above (which, by default, puts the
interface into promiscuous mode, where it ignores all dest MAC
addresses), I'd see all the packets and wonder WTF was going on.
Eventually, if I stuck with it long enough, things would "just start to
work," but I couldn't do this most of the time and had to back out
machine upgrades.
Of course, with hind site, this is fairly obvious to me, but "sticking
with it" turned out to be just waiting for the router's ARP cache entry
specific to the moved IP address to expire. I think the router's I've
been working with have a ARP timeout of 120 minutes, so I'd either have
to wait and hour (on average, two hours worst case) or get someone with
op privs on it to flush the ARP entries specific to the moved IP address.
> How can I get iptables to respond to the packets on the secondary
> interfaces? Or, how can I get the kernel to pass the packets to iptables?
>
> I understand that when the packet hits the chain, all I have to do is create
> a rule with the primary interface and use the IP address to distinguish the
> packets of different virtual addresses.
>
> If you are looking for more detail, see the email I sent on Sun, 24 Oct, at
> 9:28 p.m. (GMT -6).
I responded to your previous message both to you and the list
(http://lists.netfilter.org/pipermail/netfilter/2004-October/056725.html),
but your mail server is using very aggressive RBLs, so it rejected my
message. My guess is, unless something changed in the past week, you
probably won't see this one either, but maybe this message can help
someone else. Regardless, I think this response is better anyway.
HTH,
pete
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: iptables not responding to packets destined for subinterface
@ 2004-10-31 5:23 Gary Smith
0 siblings, 0 replies; 6+ messages in thread
From: Gary Smith @ 2004-10-31 5:23 UTC (permalink / raw)
To: Support Team, netfilter
I don't think that you can. I think that you also answered your own
question being that you must use the primary interface and use the
target destination IP address. This is what we currently do on our
firewall with 126 IP's (125 are aliases). All of the firewall traffic
is answered by the firewall and then NAT'd in/out using iptables.
Gary Wayne Smith
-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Support Team
Sent: Saturday, October 30, 2004 10:13 PM
To: netfilter@lists.netfilter.org
Subject: iptables not responding to packets destined for subinterface
My public interface has serveral IP address aliases. Only the primary
IP
address responds to traffic (ip, imcp, et al). I inserted a log
statement
at the top of each table and found that the packets destined for the
virtual
addresses never made it to any table. However, according to tcpdump, I
confirmed that the packets did get picked up by the kernel on the
secondary
address. I guess they are just not passed to iptables. Obviously, the
packet was never replied to (icmp) or acknowledged (ip) by the process.
How can I get iptables to respond to the packets on the secondary
interfaces? Or, how can I get the kernel to pass the packets to
iptables?
I understand that when the packet hits the chain, all I have to do is
create
a rule with the primary interface and use the IP address to distinguish
the
packets of different virtual addresses.
If you are looking for more detail, see the email I sent on Sun, 24 Oct,
at
9:28 p.m. (GMT -6).
Thanks for your help!
^ permalink raw reply [flat|nested] 6+ messages in thread
* iptables not responding to packets destined for subinterface
@ 2004-10-25 3:44 Support Team
2004-10-25 13:26 ` Pete Toscano
0 siblings, 1 reply; 6+ messages in thread
From: Support Team @ 2004-10-25 3:44 UTC (permalink / raw)
To: netfilter
My public interface has serveral IP address aliases. Only the primary IP
address responds to traffic (ip, imcp, et al). I inserted a log statement
at the top of each table and found that the packets destined for the virtual
addresses never made it to any table. However, according to tcpdump, I
confirmed that the packets did get picked up by the kernel on the secondary
address. I guess they are just not passed to iptables. Obviously, the
packet was never replied to (icmp) or acknowledged (ip) by the process.
How can I get iptables to respond to the packets on the secondary
interfaces? Or, how can I get the kernel to pass the packets to iptables?
I understand that when the packet hits the chain, all I have to do is create
a rule with the primary interface and use the IP address to distinguish the
packets of different virtual addresses.
Here is more details of what I have:
-----------
Interfaces:
-----------
SYNOPSIS: I have a "public" Ethernet interface that has a primary address of
1.1.1.2 on eth0. There are serveral secondary addresses. Only 1.1.1.3 on
eth0:3 is listed here. I have two "private" Ethernet interfaces, each
connected to a different physical network. The first private network has a
primary address of 10.0.0.11 on eth1. It has one secondary addresss of
10.0.0.1 on eth1:1. Finally, the second priavte interface has only one
address - 192.168.60.1 on eth2.
eth0 Link encap:Ethernet HWaddr 00:01:03:E9:3A:58
inet addr:1.1.1.2 Bcast:1.1.1.63 Mask:255.255.255.192
eth0:3 Link encap:Ethernet HWaddr 00:01:03:E9:3A:58
inet addr:1.1.1.3 Bcast:1.1.1.63 Mask:255.255.255.192
eth1 Link encap:Ethernet HWaddr 00:50:DA:24:A7:58
inet addr:10.0.0.11 Bcast:10.0.0.255 Mask:255.255.255.0
eth1:1 Link encap:Ethernet HWaddr 00:50:DA:24:A7:58
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.255.255.0
eth2 Link encap:Ethernet HWaddr 00:50:DA:94:83:3F
inet addr:192.168.60.1 Bcast:192.168.60.255 Mask:255.255.255.0
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
------------------------
Kernel IP routing table:
------------------------
SYNOPSIS: Each interface is directly connected to a physical network with
its subnet. The default gateway is a Cisco 678 DSL modem with the address
of 1.1.1.1.
Destination Gateway Genmask Flags Metric Ref Use
Iface
1.1.1.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.60.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 1.1.1.1 0.0.0.0 UG 0 0 0 eth0
---------
Iptables:
---------
SYNOPSIS: Of course, IPv4 routing is enabled. The ruleset is simple: allow
any packets destined for or originating from the device as well as anything
travesing the NAT tables. Deny all forwarded packets except outbound
traffic from the private networks or traffic that is part of an established
connection. I SNAT the private networks as the primary IP address of the
public interface. The log statements were omitted for clarity. I'd like to
SNAT on a secondary address, different ones for each private network.
However, I can't communicate using a secondary address....
Chain INPUT (policy ACCEPT 4143 packets, 604K bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 10.0.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0
10.0.0.0/24 state ESTABLISHED
15 1140 ACCEPT all -- * * 192.168.60.0/24
0.0.0.0/0
15 1140 ACCEPT all -- * * 0.0.0.0/0
192.168.60.0/24 state ESTABLISHED
Chain OUTPUT (policy ACCEPT 3917 packets, 880K bytes)
pkts bytes target prot opt in out source
destination
Chain PREROUTING (policy ACCEPT 343 packets, 43451 bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 492 packets, 44419 bytes)
pkts bytes target prot opt in out source
destination
0 0 SNAT all -- * eth0 10.0.0.0/24
0.0.0.0/0 to:1.1.1.2
15 1140 SNAT all -- * eth0 192.168.60.0/24
0.0.0.0/0 to:1.1.1.2
Chain OUTPUT (policy ACCEPT 492 packets, 44419 bytes)
pkts bytes target prot opt in out source
destination
-------------------------------------
Ping from Intenet to Primary Address:
-------------------------------------
SYNOPSIS: These are the log statements from iptables. The prefix in
parenthesis indicate which table originated the message. As expected: The
first is the ping packet hitting the PREROUTING nat table where no mangling
takes place. The second is the source ping reaching the interface after
passing the INPUT table. The last statement is the ping reply.
Oct 24 18:08:25 kernel: (prerouting) IN=eth0 OUT=
MAC=00:01:03:e9:3a:58:00:05:5e:9f:81:1c:08:00 SRC=<Internet> DST=1.1.1.2
LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41484
SEQ=0
Oct 24 18:08:25 kernel: (input) IN=eth0 OUT=
MAC=00:01:03:e9:3a:58:00:05:5e:9f:81:1c:08:00 SRC=<Internet> DST=1.1.1.2
LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41484
SEQ=0
Oct 24 18:08:25 kernel: (output) IN= OUT=eth0 SRC=1.1.1.2 DST=<Internet>
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62631 PROTO=ICMP TYPE=0 CODE=0 ID=41484
SEQ=0
-----------------------------------------
Tcpdump from Internet to Primary Address:
-----------------------------------------
SYNOPSIS: As expected, tcpdump sees the ping request and ping reply when
communicating with the primary address 1.1.1.2.
# tcpdump -vv -n -i eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
18:08:25.789975 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], length:
84) <Internet> > 1.1.1.2: icmp 64: echo request seq 0
18:08:25.790038 IP (tos 0x0, ttl 64, id 31516, offset 0, flags [none],
length: 84) 1.1.1.2 > <Internet>: icmp 64: echo reply seq 0
-------------------------------------
Ping from Intenet to SecondaryAddress:
-------------------------------------
SYNOPSIS: Iptables did not log anything when communicating with the
secondary address 1.1.1.3 I would think this indicates at least two cases:
The packet never made it to iptables or iptables didn't do anything with the
packet.
-----------------------------------------
Tcpdump from Internet to Secondary Address:
-----------------------------------------
SYNOPSIS: tcpdump sees many ping packets destined for the secondary address.
However, there are no replies. Presumably because the kernel didn't know it
needed to reply to anything.
# tcpdump -vv -n -i eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
18:09:35.220522 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], length:
84) <Internet> > 1.1.1.3: icmp 64: echo request seq 0
18:09:36.220083 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], length:
84) <Internet> > 1.1.1.3: icmp 64: echo request seq 256
---------------
Kernel Options:
---------------
SYNOPSIS: My 2.6.9 kernel has all of the advanced router options compiled
in. Eth0 and Eth1 are 3 Com 3c905c and the eth2 is 3Com 3c905b. I also
compiled in IPv6, although I'm not using it.
#
# Networking support
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_LIMIT=y
CONFIG_IP6_NF_MATCH_MAC=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_MULTIPORT=y
CONFIG_IP6_NF_MATCH_OWNER=y
CONFIG_IP6_NF_MATCH_MARK=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AHESP=y
CONFIG_IP6_NF_MATCH_LENGTH=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_MARK=y
CONFIG_IP6_NF_RAW=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
CONFIG_IPX=y
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_NET_CLS_IND=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=y
CONFIG_TYPHOON=y
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=y
# CONFIG_E100_NAPI is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_NET_POCKET is not set
If you made it this far, I *really* appreciate it. Hopefully the
information was useful
Sincerely,
Patrick Bennett Hagen
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: iptables not responding to packets destined for subinterface
2004-10-25 3:44 Support Team
@ 2004-10-25 13:26 ` Pete Toscano
0 siblings, 0 replies; 6+ messages in thread
From: Pete Toscano @ 2004-10-25 13:26 UTC (permalink / raw)
To: Support Team; +Cc: netfilter
Support Team wrote:
> My public interface has serveral IP address aliases. Only the primary IP
> address responds to traffic (ip, imcp, et al). I inserted a log statement
> at the top of each table and found that the packets destined for the virtual
> addresses never made it to any table. However, according to tcpdump, I
> confirmed that the packets did get picked up by the kernel on the secondary
> address. I guess they are just not passed to iptables. Obviously, the
> packet was never replied to (icmp) or acknowledged (ip) by the process.
>
> How can I get iptables to respond to the packets on the secondary
> interfaces? Or, how can I get the kernel to pass the packets to iptables?
>
> I understand that when the packet hits the chain, all I have to do is create
> a rule with the primary interface and use the IP address to distinguish the
> packets of different virtual addresses.
Patrick,
I don't have time to read the volume of details of your message, but the
summary sounds a lot like a problem I was having. Maybe this will help you.
I was upgrading a bunch of boxes. I'd take a spare box, configure it,
then swap it in in place of the old box. I was seeing some real
strangeness. In tcpdump, I could see the packets, but they weren't
hitting the iptables chains (verified with LOG statements at the top of
every chain in every table).
It turns out to have been an ARP cache issue. The router I was attached
to still had the MAC address of the old machine's Ethernet interface in
its cache. I could see the packets in tcpdump because it was putting
the interface in promiscuous mode and filtering on the "problem" IP
address assigned to one of my subinterfaces. It wasn't until I finally
looked at the dest MAC address in the packets I was seeing in tcpdump
(but not in iptables) and compared it to my actual MAC address that I
figured out this problem. A simple ARP cache flush on the router
cleared up the problem. (Or, if you're patient, just waiting for the
relevant entries to timeout would work too.)
Hopefully, this helps you with your problem (or maybe it'll help others).
pete
^ permalink raw reply [flat|nested] 6+ messages in thread
* iptables not responding to packets destined for subinterface
@ 2004-10-25 3:27 Support Team
0 siblings, 0 replies; 6+ messages in thread
From: Support Team @ 2004-10-25 3:27 UTC (permalink / raw)
To: netfilter
My public interface has serveral IP address aliases. Only the primary IP
address responds to traffic (ip, imcp, et al). I inserted a log statement
at the top of each table and found that the packets destined for the virtual
addresses never made it to any table. However, according to tcpdump, I
confirmed that the packets did get picked up by the kernel on the secondary
address. I guess they are just not passed to iptables. Obviously, the
packet was never replied to (icmp) or acknowledged (ip) by the process.
How can I get iptables to respond to the packets on the secondary
interfaces? Or, how can I get the kernel to pass the packets to iptables?
I understand that when the packet hits the chain, all I have to do is create
a rule with the primary interface and use the IP address to distinguish the
packets of different virtual addresses.
Here is more details of what I have:
-----------
Interfaces:
-----------
SYNOPSIS: I have a "public" Ethernet interface that has a primary address of
1.1.1.2 on eth0. There are serveral secondary addresses. Only 1.1.1.3 on
eth0:3 is listed here. I have two "private" Ethernet interfaces, each
connected to a different physical network. The first private network has a
primary address of 10.0.0.11 on eth1. It has one secondary addresss of
10.0.0.1 on eth1:1. Finally, the second priavte interface has only one
address - 192.168.60.1 on eth2.
eth0 Link encap:Ethernet HWaddr 00:01:03:E9:3A:58
inet addr:1.1.1.2 Bcast:1.1.1.63 Mask:255.255.255.192
eth0:3 Link encap:Ethernet HWaddr 00:01:03:E9:3A:58
inet addr:1.1.1.3 Bcast:1.1.1.63 Mask:255.255.255.192
eth1 Link encap:Ethernet HWaddr 00:50:DA:24:A7:58
inet addr:10.0.0.11 Bcast:10.0.0.255 Mask:255.255.255.0
eth1:1 Link encap:Ethernet HWaddr 00:50:DA:24:A7:58
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.255.255.0
eth2 Link encap:Ethernet HWaddr 00:50:DA:94:83:3F
inet addr:192.168.60.1 Bcast:192.168.60.255 Mask:255.255.255.0
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
------------------------
Kernel IP routing table:
------------------------
SYNOPSIS: Each interface is directly connected to a physical network with
its subnet. The default gateway is a Cisco 678 DSL modem with the address
of 1.1.1.1.
Destination Gateway Genmask Flags Metric Ref Use
Iface
1.1.1.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.60.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 1.1.1.1 0.0.0.0 UG 0 0 0 eth0
---------
Iptables:
---------
SYNOPSIS: Of course, IPv4 routing is enabled. The ruleset is simple: allow
any packets destined for or originating from the device as well as anything
travesing the NAT tables. Deny all forwarded packets except outbound
traffic from the private networks or traffic that is part of an established
connection. I SNAT the private networks as the primary IP address of the
public interface. The log statements were omitted for clarity. I'd like to
SNAT on a secondary address, different ones for each private network.
However, I can't communicate using a secondary address....
Chain INPUT (policy ACCEPT 4143 packets, 604K bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 10.0.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0
10.0.0.0/24 state ESTABLISHED
15 1140 ACCEPT all -- * * 192.168.60.0/24
0.0.0.0/0
15 1140 ACCEPT all -- * * 0.0.0.0/0
192.168.60.0/24 state ESTABLISHED
Chain OUTPUT (policy ACCEPT 3917 packets, 880K bytes)
pkts bytes target prot opt in out source
destination
Chain PREROUTING (policy ACCEPT 343 packets, 43451 bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 492 packets, 44419 bytes)
pkts bytes target prot opt in out source
destination
0 0 SNAT all -- * eth0 10.0.0.0/24
0.0.0.0/0 to:1.1.1.2
15 1140 SNAT all -- * eth0 192.168.60.0/24
0.0.0.0/0 to:1.1.1.2
Chain OUTPUT (policy ACCEPT 492 packets, 44419 bytes)
pkts bytes target prot opt in out source
destination
-------------------------------------
Ping from Intenet to Primary Address:
-------------------------------------
SYNOPSIS: These are the log statements from iptables. The prefix in
parenthesis indicate which table originated the message. As expected: The
first is the ping packet hitting the PREROUTING nat table where no mangling
takes place. The second is the source ping reaching the interface after
passing the INPUT table. The last statement is the ping reply.
Oct 24 18:08:25 kernel: (prerouting) IN=eth0 OUT=
MAC=00:01:03:e9:3a:58:00:05:5e:9f:81:1c:08:00 SRC=<Internet> DST=1.1.1.2
LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41484
SEQ=0
Oct 24 18:08:25 kernel: (input) IN=eth0 OUT=
MAC=00:01:03:e9:3a:58:00:05:5e:9f:81:1c:08:00 SRC=<Internet> DST=1.1.1.2
LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41484
SEQ=0
Oct 24 18:08:25 kernel: (output) IN= OUT=eth0 SRC=1.1.1.2 DST=<Internet>
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62631 PROTO=ICMP TYPE=0 CODE=0 ID=41484
SEQ=0
-----------------------------------------
Tcpdump from Internet to Primary Address:
-----------------------------------------
SYNOPSIS: As expected, tcpdump sees the ping request and ping reply when
communicating with the primary address 1.1.1.2.
# tcpdump -vv -n -i eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
18:08:25.789975 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], length:
84) <Internet> > 1.1.1.2: icmp 64: echo request seq 0
18:08:25.790038 IP (tos 0x0, ttl 64, id 31516, offset 0, flags [none],
length: 84) 1.1.1.2 > <Internet>: icmp 64: echo reply seq 0
-------------------------------------
Ping from Intenet to SecondaryAddress:
-------------------------------------
SYNOPSIS: Iptables did not log anything when communicating with the
secondary address 1.1.1.3 I would think this indicates at least two cases:
The packet never made it to iptables or iptables didn't do anything with the
packet.
-----------------------------------------
Tcpdump from Internet to Secondary Address:
-----------------------------------------
SYNOPSIS: tcpdump sees many ping packets destined for the secondary address.
However, there are no replies. Presumably because the kernel didn't know it
needed to reply to anything.
# tcpdump -vv -n -i eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
18:09:35.220522 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], length:
84) <Internet> > 1.1.1.3: icmp 64: echo request seq 0
18:09:36.220083 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], length:
84) <Internet> > 1.1.1.3: icmp 64: echo request seq 256
---------------
Kernel Options:
---------------
SYNOPSIS: My 2.6.9 kernel has all of the advanced router options compiled
in. Eth0 and Eth1 are 3 Com 3c905c and the eth2 is 3Com 3c905b. I also
compiled in IPv6, although I'm not using it.
#
# Networking support
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_LIMIT=y
CONFIG_IP6_NF_MATCH_MAC=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_MULTIPORT=y
CONFIG_IP6_NF_MATCH_OWNER=y
CONFIG_IP6_NF_MATCH_MARK=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AHESP=y
CONFIG_IP6_NF_MATCH_LENGTH=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_MARK=y
CONFIG_IP6_NF_RAW=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
CONFIG_IPX=y
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_NET_CLS_IND=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=y
CONFIG_TYPHOON=y
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=y
# CONFIG_E100_NAPI is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_NET_POCKET is not set
If you made it this far, I *really* appreciate it. Hopefully the
information was useful
Sincerely,
Patrick Bennett Hagen
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-01 13:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-31 5:12 iptables not responding to packets destined for subinterface Support Team
2004-11-01 13:03 ` Pete Toscano
-- strict thread matches above, loose matches on Subject: below --
2004-10-31 5:23 Gary Smith
2004-10-25 3:44 Support Team
2004-10-25 13:26 ` Pete Toscano
2004-10-25 3:27 Support Team
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.