iptables forwarding question

[Benjamin Franz]

On Fri, 17 Mar 2006, James Pifer wrote:

>
>> Define 'performance is terrible'. That isn't a very useful description of the problem.
>>
>> What do traceroute and ping look like from each end? Are you seeing lots
>> of packet loss or RTTs or is something else entirely happening? What
>> _other_ iptable rules are in your system? What does your route table look
>> like? Are you seeing anything in /var/log/messages?
>>
>> You haven't given anywhere near enough information to guess at causes.
>> --
>> Benjamin Franz
>>
>> If you can't handle reality, it *will* handle you.
>>
>
> No, I sure didn't give much info.
>
> I don't have access to server2.

Not a ton of suggestions based on what you sent. Try 'ping'ing server2. 
Your log suggests you may have noticable packet loss. 'ping' will tell you 
if that is your problem.

- Benjamin Franz



>
> By terrible performance I mean the audio I hear on my end is really
> choppy, or is full of interference. It's actually difficult to explain
> the noise.
>
> I'm doing an ethereal capture and I see the packets going between the
> phone and server2. The only negative thing I see in the trace is my ppp0
> address replying to server2 that:
> Protocol: ICMP; Info: Destination unreachable (Port unreachable)
>
> In messages I see a lot of this when I try to use the phone:
> Mar 17 10:50:18 laptop pptp[31007]: anon log[decaps_gre:pptp_gre.c:407]:
> buffering packet 1363 (expecting 1362, lost or reordered)
> Mar 17 10:50:18 laptop pptp[31007]: anon log[decaps_gre:pptp_gre.c:407]:
> buffering packet 1364 (expecting 1362, lost or reordered)
> Mar 17 10:50:20 laptop pptp[31007]: anon log[decaps_gre:pptp_gre.c:407]:
> buffering packet 1410 (expecting 1408, lost or reordered)
>
> Here are the other rules:
> # iptables -L;iptables -t nat -L
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  10.0.0.0/8           anywhere
> ACCEPT     all  --  10.0.0.0/8           anywhere
> ACCEPT     all  --  anywhere             10.0.0.0/8
> TCPMSS     tcp  --  anywhere             anywhere            tcp
> flags:SYN,RST/SYN TCPMSS clamp to PMTU
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  10.0.0.0/8           anywhere
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             10.0.0.0/8
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination
> MASQUERADE  all  --  anywhere             anywhere
>
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
> DNAT       all  --  10.96.26.42          10.96.7.149
> to:192.168.0.9
>
> route table is:
> # route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> vpn1		192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0
> 10.96.7.6       *               255.255.255.255 UH    0      0        0
> ppp0
> 192.168.1.0     *               255.255.255.0   U     0      0        0
> wlan0
> 192.168.0.0     *               255.255.255.0   U     0      0        0
> eth0
> 169.254.0.0     *               255.255.0.0     U     0      0        0
> wlan0
> 10.0.0.0        *               255.0.0.0       U     0      0        0
> ppp0
> default         192.168.1.1     0.0.0.0         UG    0      0        0
> wlan0
>
> I have these interfaces and the machine is acting as a router:
> wlan0	192.168.1.0 network
> eth0	192.168.0.0 network
> ppp0	10.96.7.0 network
>
> Let me try to explain why I have both a 192.168.1.0 and a 192.168.0.0.
> There is another route to the remote network through a branch office
> VPN. I did not want any confusion while trying to make this work, so I
> wanted the phone to be on a different subnet (logically). So the only
> things on 192.168.0.0 are the phone and eth0 in my laptop. I don't
> believe this is causing any issues.
>
> Thanks,
> James
>
>