I found the problem! It was me and it was dumb...
This was the network layout:
10.10.10.0/24 1.2.3.0/27
10.10.10.n
internal hosts
|
<----+-----+--------+ +-------+------>to the Internet
| | | |
Proxied | | |
H.323 device Firewall Router
eth1 eth0
1.2.3.11 10.10.10.1 1.2.3.2 1.2.3.1
1.2.3.2
The problem was, before doing proxy ARP, my h.323 device was set up with
NAT and it had a 10.nnn IP Address. The outside interface on my
firewall had 1.2.3.11 as a secondary address and NATed the appropriate
stuff to the H.323 device. I changed all that to use proxy ARP - but I
forgot to get rid of the secondary IP Address on eth0 of the firewall.
I changed all my scripts but forgot to change that IP Address in the
live, running system. Woops!
- Greg Scott
-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Greg Scott
Sent: Monday, February 27, 2006 6:28 AM
To: gypsy; lartc@mailman.ds9a.nl
Subject: RE: [LARTC] Proxy ARP and UDP
OK -
Here is how I am running tcpdump. Not really much to tell.
In one window:
tcpdump -i eth1 -n
And then in another window:
tcpdump -i eth0 -n
If I were filtering anything with tcpdump I would be pretty embarrassed.
:)
eth0 is the interface pointing to the Internet. eth1 is inside. For
every several thousand packets that tcpdump shows me on eth1, I see
maybe one or two on eth0 when running any traffic at all between the
Internet and my proxy ARP''d device.
Since these are conversations with a host on the other side of the
Internet I should see packets flying across both interfaces. But I
don''t. I only see packets flying across the inside interface, except
for a very small subset that I see on the outside interface.
This behavior makes no sense. How is it possible that any connection
between my proxy ARP''d host and the Internet works if virtually no
traffic is moving across the outside interface???? The obvious answer -
it isn''t. Traffic must in fact be moving across the outside interface,
otherwise my proxy ARP''d device would never see it. So the only
possible conclusion is, the traffic must he happening someplace where
tcpdump and evidently also the traffic shaping code does not see it.
Don''t believe me? Try it yourself. Send a bunch of pings from
somewhere across the Internet to your proxy ARP''d device and watch your
outside interface. I''ll bet you don''t see them. But your
proxy ARP''d
device will see them, assuming you have some firewall rules that allow
this. It will reply and the requesting host outside the Internet will
see the echo reply packets coming back. But your outside firewall
interface will look dead even though the echo request/reply packets are
clearly flying across it. Look for yourself if you don''t believe me.
Here is my traffic shaping script. Again, pretty basic stuff - nothing
fancy. And it isn''t relevant to my issue.
TC="/sbin/tc"
$TC qdisc del dev $INET_IFACE root
$TC qdisc del dev $TRUSTED1_IFACE root
$TC qdisc del dev $DMZ_IFACE root
$TC qdisc add dev $INET_IFACE root handle 1: prio # This *instantly*
creates classes 1:1, 1:2, 1:3 $TC qdisc add dev $TRUSTED1_IFACE root
handle 2: prio # This *instantly* creates classes 2:1, 2:2, 2:3
$TC qdisc add dev $INET_IFACE parent 1:1 handle 11: pfifo $TC qdisc add
dev $INET_IFACE parent 1:2 handle 12: pfifo $TC qdisc add dev
$INET_IFACE parent 1:3 handle 13: pfifo
$TC qdisc add dev $TRUSTED1_IFACE parent 2:1 handle 21: pfifo $TC qdisc
add dev $TRUSTED1_IFACE parent 2:2 handle 22: pfifo $TC qdisc add dev
$TRUSTED1_IFACE parent 2:3 handle 23: pfifo
#
# This assigns traffic to/from $PUBLIC_VTC1_IP and $PRIVATE_VTC1_IP # to
the highest priority band of the queue for the appropriate # interface,
and the rest to the next-highest proirity band.
#
# VTC1
$TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \
match ip dst $PUBLIC_VTC1_IP flowid 1:1 $TC filter add dev $INET_IFACE
parent 1:0 protocol ip prio 1 u32 \
match ip src $PUBLIC_VTC1_IP flowid 1:1
# VTC2
$TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \
match ip dst $PUBLIC_VTC2_IP flowid 1:1 $TC filter add dev $INET_IFACE
parent 1:0 protocol ip prio 1 u32 \
match ip src $PUBLIC_VTC2_IP flowid 1:1
# Everyone else
$TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 2 u32 \
match ip src 0.0.0.0/0 flowid 1:2
$TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 2 u32 \
match ip src 0.0.0.0/0 flowid 2:2
exit
> Greg,
>
>Please, if you want answers, provide enough information for us to help.
>
>In the absence of any shaping configuration script, it is useless to
>speculate about why you see nothing being shaped. I will say that UDP
>is not "protocol ip". Neither is ARP nor ICMP.
>
>In the absence of the parameters you are passing to tcpdump, nothing
can >be said about why you are not seeing the expected traffic on the
external IF.>
>Run ''cat /proc/net/ip_conntrack | grep udp''
>
>There is nothing wrong with your .27 kernel! I have done something
>similar to what you seem to be trying to do for years running kernels
>from 2.4.25 through .32 and never had any problem at all with proxy ARP
>(except for the mental part ;)
>--
>gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
