Re: Help: iptables NAT broken with pppoe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Fist, thanks a lot for your reply!

You are quite welcome.

I'm not sure why it's happening but your PMac G4 system is sending reset packets in response to the responses from the server.


Ouch! That's indeed very strange. I can only repeat that it *did* work using isdn, so apparently there is some pppoe related porblem?

I'm not doubting you that it did work, though I have NO idea why it is not working at the moment. You might want to try (re)posting your question to a different mail list (suggestions any one?) or see if any one else on this list might be able to help you more than I can. (Any one care to jump in here and take over where I'm coming up short?)

Have you tried using an SNAT rule temporarily on your POSTROUTING chain to see if the problem is with the MASQUERADE rule?

Same effect - replaced the masquerade rule by

Just one comment "Hmmmm....".

ppp0ip=84.44.130.37
iptables -t nat -A POSTROUTING -s 192.168.42.0/24 -o ppp0 -j SNAT \
- --to-source $ppp0ip

but tcpdump still reports

21:50:33.986790 IP 84.44.130.37.49224 > 213.95.27.115.80: S 3806917882:3806917882(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 380633236 0>
21:50:34.047457 IP 213.95.27.115.80 > 84.44.130.37.49224: S 118817856:118817856(0) ack 3806917883 win 5792 <mss 1460,nop,nop,timestamp  1571974157 380633236,nop,wscale 2>
21:50:34.047558 IP 84.44.130.37.49224 > 213.95.27.115.80: R 3806917883:3806917883(0) win 0

*nod*

The modules ipt_MASQUERADE and iptable_nat *are* loaded, btw.

Also, what is your "echo 2 > /proc/sys/net/ipv4/ip_dynaddr" doing for you?

I don't see any messages in /var/log messages or in dmesg, if you mean that. Or did I miss your point here? I found some howto where they stated this would be necessary...

Ok. I've never heard or seen reference to /proc/sys/net/ipv4/ip_dynaddr before and I'm not sure what its purpose is let alone that it is requried. Does any one have any more information on what it is and what its purpose is?

You might want to check to make sure that reverse path filtering
is not turned on by default. You might also want to turn on verbose routing messages to see if there is any thing useful being reported.

Hmmm, can you tell me how I actually check reverse path filtering and turn debugging on? Sorry, I'm neither a iptables nor a kernel guru :-/

Take a look at /proc/sys/net/ipv4/conf/<device|all|default>/rp_filter to see if it is "1" or "0". As I understand it reverse path filter(ing) is a kernel level filter feature that will only allow traffic with a specific source address to come in on the interface that it is connected to. This would explain why you might be getting the reset packet if reverse path filtering is turned on on your eth0 device.

Thanks a lot for your help,

No problem. :)


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux