Help: iptables NAT broken with pppoe

Help: iptables NAT broken with pppoe

[Albrecht Dreß]

[-- Attachment #1.1: Type: text/plain, Size: 2186 bytes --]

Hi,

I am new to this list, so please xcuse me if this is a dumb question.

I have a small home network looking as follows:

         192.168.42.3
         -----------     -------
        | PMac G4   |   |       |---DSL Modem (ppp0)
ISDN---|ippp0  eth0|---|Switch |---two computers, printer (192.168.42.x)
         -----------     -------

The machine marked as "PMac G4" is a Powermac G4/800 "Silver", running  
Linux 2.6.11.4 on the Yellowdog 4.01 disto, which includes iptables v1.2.9.

I had an "old" setup with the G4 working as router via the isdn adaptor,  
which worked flawlessly. I now switched to ADSL, so I removed the ISDN  
connection and just changed to ppp0 using the kernel-based pppoe driver.

Now the machines in my "local" net can still connect the G4, but  
nat/masquerading to the outside world fails. I stripped down my ipfilter  
config to a completely open one (see attached fw.sh script), but still had  
no success.

Running tcpdump on both eth0 and ppp0, I saw that e.g. a http request from  
one of the local machines (see 2nd attachment) is actually passed via ppp0  
to the remote host. However, all reply packets from that box are never  
passed back to eth0, so this looks to me as if masquerading somehow fails.

Does anyone know what I missed here? The same iptables setup (actually a  
lot stricter, i.e. a "real" firewall) worked fine with isdn/ippp0. I also  
verified that it is at least technically working; running the G4 under  
MacOS 10.3.9 client, with a little ipfw and natd fiddling the machine is  
doing nat as expected. However, as I usually use Linux, a running nat  
setup with iptables is really important for me.

HELP - I am really lost here, so any help/pointer would be really welcome!

Thanks in advance, Albrecht.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
    GnuPG public key:  http://home.arcor.de/dralbrecht.dress/pubkey.asc
_________________________________________________________________________

[-- Attachment #1.2: fw.sh --]
[-- Type: application/x-shellscript, Size: 426 bytes --]

[-- Attachment #1.3: tcpdump --]
[-- Type: text/plain, Size: 4783 bytes --]

[root@antares root]# tcpdump -nn -i eth0 tcp port 80
18:16:21.012143 IP 192.168.42.4.49223 > 213.95.27.115.80: S 2685214081:2685214081(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2148180757 0>
18:16:23.779283 IP 192.168.42.4.49223 > 213.95.27.115.80: S 2685214081:2685214081(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2148180762 0>
18:16:26.626863 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2148180768 0>
18:16:29.278717 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2148180773 0>
18:16:32.278383 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2148180779 0>
18:16:35.278053 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460>
18:16:38.277733 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460>
18:16:41.277416 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460>
18:16:47.276686 IP 192.168.42.4.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1460>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[root@antares root]# tcpdump -nn -i ppp0 tcp port 80 2> tcpdump.ppp0
18:16:21.012206 IP 84.44.131.113.49223 > 213.95.27.115.80: S 2685214081:2685214081(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180757 0>
18:16:21.085651 IP 213.95.27.115.80 > 84.44.131.113.49223: S 2677460604:2677460604(0) ack 2685214082 win 5792 <mss 1460,nop,nop,timestamp 1472713132 2148180757,nop,wscale 2>
18:16:21.085748 IP 84.44.131.113.49223 > 213.95.27.115.80: R 2685214082:2685214082(0) win 0
18:16:23.779332 IP 84.44.131.113.49223 > 213.95.27.115.80: S 2685214081:2685214081(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180762 0>
18:16:23.841268 IP 213.95.27.115.80 > 84.44.131.113.49223: S 2680216981:2680216981(0) ack 2685214082 win 5792 <mss 1460,nop,nop,timestamp 1472715888 2148180762,nop,wscale 2>
18:16:23.841326 IP 84.44.131.113.49223 > 213.95.27.115.80: R 2685214082:2685214082(0) win 0
18:16:26.626918 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180768 0>
18:16:26.689960 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2688743097:2688743097(0) ack 2390183935 win 5792 <mss 1460,nop,nop,timestamp 1472718737 2148180768,nop,wscale 2>
18:16:26.690000 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0
18:16:29.278746 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180773 0>
18:16:29.343266 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2691397130:2691397130(0) ack 2390183935 win 5792 <mss 1460,nop,nop,timestamp 1472721391 2148180773,nop,wscale 2>
18:16:29.343295 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0
18:16:32.278425 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180779 0>
18:16:32.341042 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2694396243:2694396243(0) ack 2390183935 win 5792 <mss 1460,nop,nop,timestamp 1472724390 2148180779,nop,wscale 2>
18:16:32.341114 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0
18:16:35.278094 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452>
18:16:35.339906 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2697395925:2697395925(0) ack 2390183935 win 5840 <mss 1460>
18:16:35.339928 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0
18:16:38.277765 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452>
18:16:38.334399 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2700391695:2700391695(0) ack 2390183935 win 5840 <mss 1460>
18:16:38.334470 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0
18:16:41.277463 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452>
18:16:41.334072 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2703391278:2703391278(0) ack 2390183935 win 5840 <mss 1460>
18:16:41.334119 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0
18:16:47.276735 IP 84.44.131.113.49224 > 213.95.27.115.80: S 2390183934:2390183934(0) win 65535 <mss 1452>
18:16:47.333126 IP 213.95.27.115.80 > 84.44.131.113.49224: S 2709392375:2709392375(0) ack 2390183935 win 5840 <mss 1460>
18:16:47.333171 IP 84.44.131.113.49224 > 213.95.27.115.80: R 2390183935:2390183935(0) win 0



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Help: iptables NAT broken with pppoe

[Taylor, Grant]

> [root@antares root]# tcpdump -nn -i ppp0 tcp port 80 2> tcpdump.ppp0
> 18:16:21.012206 IP 84.44.131.113.49223 > 213.95.27.115.80: S 2685214081:2685214081(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180757 0>
> 18:16:21.085651 IP 213.95.27.115.80 > 84.44.131.113.49223: S 2677460604:2677460604(0) ack 2685214082 win 5792 <mss 1460,nop,nop,timestamp 1472713132 2148180757,nop,wscale 2>
> 18:16:21.085748 IP 84.44.131.113.49223 > 213.95.27.115.80: R 2685214082:2685214082(0) win 0
> 18:16:23.779332 IP 84.44.131.113.49223 > 213.95.27.115.80: S 2685214081:2685214081(0) win 65535 <mss 1452,nop,wscale 0,nop,nop,timestamp 2148180762 0>
> 18:16:23.841268 IP 213.95.27.115.80 > 84.44.131.113.49223: S 2680216981:2680216981(0) ack 2685214082 win 5792 <mss 1460,nop,nop,timestamp 1472715888 2148180762,nop,wscale 2>
> 18:16:23.841326 IP 84.44.131.113.49223 > 213.95.27.115.80: R 2685214082:2685214082(0) win 0

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.  Have you tried using an SNAT rule temporarily on your POSTROUTING chain to see if the problem is with the MASQUERADE rule?  Also, what is your "echo 2 > /proc/sys/net/ipv4/ip_dynaddr" doing for you?  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.



Grant. . . .

Re: Help: iptables NAT broken with pppoe

[Albrecht Dreß]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Fist, thanks a lot for your reply!

Am 07.05.05 08:12 schrieb(en) Taylor, Grant:
> 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?

> 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

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

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...

> 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 :-/

Thanks a lot for your help,

cheers, Albrecht.

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Drefl  -  Johanna-Kirchner-Strafle 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
    GnuPG public key:  http://home.arcor.de/dralbrecht.dress/pubkey.asc
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCfR5On/9unNAn/9ERAq1EAJ9LcwjnujvlQRKzne9m8Q64bYY1VQCdHxNk
Ddfy9kIaOz/9IssqpR74iK4=
=ENLW
-----END PGP SIGNATURE-----

Re: Help: iptables NAT broken with pppoe

[Taylor, Grant]

> 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.  :)

Re: Help: iptables NAT broken with pppoe

[Jason Opperisano]

On Mon, May 09, 2005 at 12:56:13AM -0500, Taylor, Grant wrote:
> 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?

************************************************************************
$ cat /usr/src/linux-2.6.11/Documentation/networking/ip_dynaddr.txt 

  IP dynamic address hack-port v0.03
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  This stuff allows diald ONESHOT connections to get established
  by dynamically changing packet source address (and socket's if
  local procs).  It is implemented for TCP diald-box connections(1)
  and IP_MASQuerading(2).

  1)  Socket (and packet) source address is rewritten ON RETRANSMISSIONS
      while in SYN_SENT state (diald-box processes).
  2)  Out-bounded MASQueraded source address changes ON OUTPUT (when
      internal host does retransmission) until a packet from outside is
      received by the tunnel.

  This is specially helpful for auto dialup links (diald), where the
  ``actual'' outgoing address is unknown at the moment the link is going
  up. So, the *same* (local AND masqueraded) connections requests that
  bring the link up will be able to get established.

  [*] At boot, by default no address rewriting is attempted. 
  To enable:
     # echo 1 > /proc/sys/net/ipv4/ip_dynaddr
  To enable verbose mode:
     # echo 2 > /proc/sys/net/ipv4/ip_dynaddr
  To disable (default)
     # echo 0 > /proc/sys/net/ipv4/ip_dynaddr

  Enjoy!

  -- Juanjo  <jjciarla@raiz.uncu.edu.ar>
************************************************************************

-j

--
"Narrator: Remember, nothing says "good job" like a firm, open-palm
 slap on the behind."
        --Family Guy

Re: Help: iptables NAT broken with pppoe

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Am 09.05.05 07:56 schrieb(en) Taylor, Grant:
>> 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.

Set them all to either 0 or 1 - still the same picture, the reply from the  
remote server results (in tcpdump) in the one with "win 0" being sent back  
instead of passing it to eth0.

Any idea whom I could ask here for help? Maybe the Linux kernel mailing  
list? Or is there a more specialised one for networking issues?

Cheers, Albrecht.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
    GnuPG public key:  http://home.arcor.de/dralbrecht.dress/pubkey.asc
_________________________________________________________________________

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Help: iptables NAT broken with pppoe

[Taylor, Grant]

> Set them all to either 0 or 1 - still the same picture, the reply from 
> the  remote server results (in tcpdump) in the one with "win 0" being 
> sent back  instead of passing it to eth0.

Hmm.  Would it be possible to see the output of iptables-save?  I'm just wondering if there is something else in the mix that is messing things up.

> Any idea whom I could ask here for help? Maybe the Linux kernel mailing  
> list? Or is there a more specialised one for networking issues?

Sorry, I don't know off hand where to send you.  Any one else have any advice here?



Grant. . . .

Re: Help: iptables NAT broken with pppoe

[Andy Furniss]

Taylor, Grant wrote:
>> Set them all to either 0 or 1 - still the same picture, the reply from 
>> the  remote server results (in tcpdump) in the one with "win 0" being 
>> sent back  instead of passing it to eth0.
> 
> 
> Hmm.  Would it be possible to see the output of iptables-save?  I'm just 
> wondering if there is something else in the mix that is messing things up.
> 
>> Any idea whom I could ask here for help? Maybe the Linux kernel 
>> mailing  list? Or is there a more specialised one for networking issues?
> 
> 
> Sorry, I don't know off hand where to send you.  Any one else have any 
> advice here?

One thought - the tcpdump is incomplete by just looking at port 80 you 
can't see what ICMP are being sent.

Andy.

Re: Help: iptables NAT broken with pppoe

[Andy Furniss]

Andy Furniss wrote:
> Taylor, Grant wrote:
> 
>>> Set them all to either 0 or 1 - still the same picture, the reply 
>>> from the  remote server results (in tcpdump) in the one with "win 0" 
>>> being sent back  instead of passing it to eth0.
>>
>>
>>
>> Hmm.  Would it be possible to see the output of iptables-save?  I'm 
>> just wondering if there is something else in the mix that is messing 
>> things up.
>>
>>> Any idea whom I could ask here for help? Maybe the Linux kernel 
>>> mailing  list? Or is there a more specialised one for networking issues?
>>
>>
>>
>> Sorry, I don't know off hand where to send you.  Any one else have any 
>> advice here?
> 
> 
> One thought - the tcpdump is incomplete by just looking at port 80 you 
> can't see what ICMP are being sent.
> 
> Andy.

Add OP to CC

Re: Help: iptables NAT broken with pppoe

[Albrecht =?unknown-8bit?q?Dre=DF?=]

> One thought - the tcpdump is incomplete by just looking at port 80 you 
> can't see what ICMP are being sent.

Well, the idea was to reduce the amount of data reported by tcpdump. My naive assumption was that running the two tcpdump's on eth0 and ppp0, I would see the request packet coming from eth0, the masqueraded one on ppp0, and the same process in the opposite direction for the reply.

Why do you think it would be important to see the icmp's, too?

Cheers, Albrecht.

Machen Sie aus 14 Cent spielend bis zu 100 Euro!
Die neue Gaming-Area von Arcor - über 50 Onlinespiele im Angebot.
http://www.arcor.de/rd/emf-gaming-1

Re: Help: iptables NAT broken with pppoe

[Andy Furniss]

Albrecht Dreß wrote:
>>One thought - the tcpdump is incomplete by just looking at port 80 you 
>>can't see what ICMP are being sent.
> 
> 
> Well, the idea was to reduce the amount of data reported by tcpdump. My naive assumption was that running the two tcpdump's on eth0 and ppp0, I would see the request packet coming from eth0, the masqueraded one on ppp0, and the same process in the opposite direction for the reply.
> 
> Why do you think it would be important to see the icmp's, too?

Just thought it would be better to be able to see all what was going on 
- I have no specific ideas, though.

Andy.

Re: Help: iptables NAT broken with pppoe

[Albrecht Dreß]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 09.05.05 20:43 schrieb(en) Taylor, Grant:
> Hmm.  Would it be possible to see the output of iptables-save?  I'm just  
> wondering if there is something else in the mix that is messing things  
> up.

[root@antares root]# iptables-save
# Generated by iptables-save v1.2.9 on Wed May 11 18:55:34 2005
*filter
:INPUT ACCEPT [499:173300]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [464:105581]
- -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS  
- --clamp-mss-to-pmtu
COMMIT
# Completed on Wed May 11 18:55:34 2005
# Generated by iptables-save v1.2.9 on Wed May 11 18:55:34 2005
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [1:74]
:OUTPUT ACCEPT [1:74]
- -A POSTROUTING -s 192.168.42.0/255.255.255.0 -o ppp0 -j MASQUERADE
COMMIT
# Completed on Wed May 11 18:55:34 2005

Doesn't look wrong, does it?

> Sorry, I don't know off hand where to send you.  Any one else have any  
> advice here?

I just sent a message to the linux kernel networking list... I'll let you  
know if there is any useful reply.

Thanks, Albrecht.


- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Drefl  -  Johanna-Kirchner-Strafle 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
    GnuPG public key:  http://home.arcor.de/dralbrecht.dress/pubkey.asc
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCgjoen/9unNAn/9ERApMEAKCcmNdn8620OiBnWtjPn/cVKTw3EwCfX5IE
oKfiG6apFL9Cq9OIRvEFkf4=
=RmIH
-----END PGP SIGNATURE-----

Re: Help: iptables NAT broken with pppoe

[Taylor, Grant]

> [root@antares root]# iptables-save
> # Generated by iptables-save v1.2.9 on Wed May 11 18:55:34 2005
> *filter
> :INPUT ACCEPT [499:173300]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [464:105581]
> - -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS  - 
> --clamp-mss-to-pmtu
> COMMIT
> # Completed on Wed May 11 18:55:34 2005
> # Generated by iptables-save v1.2.9 on Wed May 11 18:55:34 2005
> *nat
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [1:74]
> :OUTPUT ACCEPT [1:74]
> - -A POSTROUTING -s 192.168.42.0/255.255.255.0 -o ppp0 -j MASQUERADE
> COMMIT
> # Completed on Wed May 11 18:55:34 2005
> 
> Doesn't look wrong, does it?

No, your firewall looks to be completely open like it needs to be.

> I just sent a message to the linux kernel networking list... I'll let 
> you  know if there is any useful reply.

Could you reply with any updates that you have as I'd like to stay abreast on this if possible.



Grant. . . .

Re: Help: iptables NAT broken with pppoe

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 9 May 2005, Taylor, Grant wrote:


 	[SNIP]

>
> *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...


ip_dynaddr
- ----------

Enable dynamic  socket  address rewriting on interface address change. 
This is useful for dialup interface with changing IP addresses.


located under the kernel tree is the doc on pro/sys  sysctl;

/usr/src/linux-<kern ver>/Documentation/filesystems/proc.txt


Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCgCPYst+vzJSwZikRAlC3AKCr3sM3oO7fz3V7uutaLlKCnmsbkQCgyLjq
bgu2VI/ftJQ4II5auBy6CTY=
=BiR3
-----END PGP SIGNATURE-----