st1\:*{behavior:url(#default#ieooui) }
Hi,
First of all, thanks to everyone on this list (particularlyTom), I#8217;ve
managed to learn a great deal since I started working withShorewall and
monitoring this mailing list!
So I come to you today with an interesting problem (at leastfor me), concerning
the use of Shorewall with an rp-pppoe managed connection.
Whenever I start big transfers on my NATed machines that arefast enough to use
up all my bandwidth, the pppoe connection shuts down after aminute or two
(sometimes three) of intense download. This is what thepppoe/pppd log entries
say:
Dec 11 21:32:05helios pppoe[11017]: Session 437 terminated -- received PADT from
peer
Dec 11 21:32:05helios pppoe[11017]: Sent PADT
Dec 11 21:32:05helios pppd[10919]: Modem hangup
Dec 11 21:32:05helios pppd[10919]: Connection terminated.
Dec 11 21:32:05helios pppd[10919]: Connect time 15.0 minutes.
Dec 11 21:32:05helios pppd[10919]: Sent 3675916 bytes, received 124650419 bytes.
I am pretty sure that this issue is related to Shorewall oneway or another,
because if I try the exact same download on my Shorewallmachine, all goes well.
The problem only occurs when downloading from a NATedmachine.
I#8217;ve examined my Shorewall logs, but there seems to benothing out of the
ordinary. Here are the last few entries before the pppoe connection#8217;sdeath:
Dec 11 21:31:52helios Shorewall:net2all:DROP: IN=ppp0 OUT= MAC= SRC=80.130.141.9
DST=207.112.44.134LEN=64TOS=00PREC=0x00 TTL=116 ID=63678 CE DF PROTO=TCP
SPT=3659 DPT=4662SEQ=1476083001 ACK=0WINDOW=54784 SYN URGP=0
Dec 11 21:31:56helios Shorewall:net2all:DROP: IN=ppp0 OUT= MAC=
SRC=132.210.35.238 DST=207.112.44.134LEN=60TOS=00PREC=0x00 TTL=41 ID=48037 CE DF
PROTO=TCP SPT=48626 DPT=4662SEQ=920203276 ACK=0WINDOW=5840 SYN URGP=0
Dec 11 21:31:59helios Shorewall:net2all:DROP: IN=ppp0 OUT= MAC=
SRC=132.210.35.238 DST=207.112.44.134LEN=60TOS=00PREC=0x00 TTL=41 ID=48038 CE DF
PROTO=TCP SPT=48626 DPT=4662SEQ=920203276 ACK=0WINDOW=5840 SYN URGP=0
(as you can see, I#8217;m getting swarmed by unrequested eMulepackets #8211;
which I don#8217;t even have installed on any machine)
Oh, and CLAMPMSS=Yes is set in my shorewall.conf.
Has anyone ever encountered this problem before?
Thanks in advance for all your help!
---------------------------------
Post your free ad now! Yahoo! Canada Personals
On December 11, 2003 09:46 pm, Dominique Archambault wrote:> Dec 11 21:32:05helios pppoe[11017]: Session 437 terminated -- received PADT > from peer > > Dec 11 21:32:05helios pppoe[11017]: Sent PADT > Dec 11 21:32:05helios pppd[10919]: Modem hangup > Dec 11 21:32:05helios pppd[10919]: Connection terminated. > Dec 11 21:32:05helios pppd[10919]: Connect time 15.0 minutes. > Dec 11 21:32:05helios pppd[10919]: Sent 3675916 bytes, received 124650419 > bytes. > > I am pretty sure that this issue is related to Shorewall oneway or another, > because if I try the exact same download on my Shorewallmachine, all goes > well. The problem only occurs when downloading from a NATedmachine.You received a PADT packet, stands for "PPPoE Active Discovery Terminate". Your ISP intentionally disconnected you. Does your DSL provider have policies disallowing NAT? I''m not sure how they could detect whether or not you are running NAT but they might just be making an "educated" guess. -- Fraser Campbell <fraser@wehave.net> http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux
>> Dec 11 21:32:05helios pppoe[11017]: Session 437 terminated --received PADT>> from peer >> >> Dec 11 21:32:05helios pppoe[11017]: Sent PADT >> Dec 11 21:32:05helios pppd[10919]: Modem hangup >> Dec 11 21:32:05helios pppd[10919]: Connection terminated. >> Dec 11 21:32:05helios pppd[10919]: Connect time 15.0 minutes. >> Dec 11 21:32:05helios pppd[10919]: Sent 3675916 bytes, received124650419>> bytes. >> >> I am pretty sure that this issue is related to Shorewall oneway oranother,>> because if I try the exact same download on my Shorewallmachine, allgoes>> well. The problem only occurs when downloading from a NATedmachine. > >You received a PADT packet, stands for "PPPoE Active DiscoveryTerminate".>Your ISP intentionally disconnected you. > >Does your DSL provider have policies disallowing NAT? I''m not sure howthey>could detect whether or not you are running NAT but they might just bemaking>an "educated" guess.That would be surprising, considering that I have no problem using Linksys or D-Link routers (BEFSR41 & DI-614+ respectively). Unless Shorewall implements NAT differently, thus allowing my ISP to detect I have a NAT set up? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca
--- Dominique Archambault <apox@yahoo.com> wrote:> >> Dec 11 21:32:05helios pppoe[11017]: Session 437 terminated -- > received PADT > >> from peer > >> > >> Dec 11 21:32:05helios pppoe[11017]: Sent PADT > >> Dec 11 21:32:05helios pppd[10919]: Modem hangup > >> Dec 11 21:32:05helios pppd[10919]: Connection terminated. > >> Dec 11 21:32:05helios pppd[10919]: Connect time 15.0 minutes. > >> Dec 11 21:32:05helios pppd[10919]: Sent 3675916 bytes, received > 124650419 > >> bytes. > >> > >> I am pretty sure that this issue is related to Shorewall oneway or > another, > >> because if I try the exact same download on my Shorewallmachine, > all > goes > >> well. The problem only occurs when downloading from a > NATedmachine. > > > >You received a PADT packet, stands for "PPPoE Active Discovery > Terminate". > >Your ISP intentionally disconnected you. > > > >Does your DSL provider have policies disallowing NAT? I''m not sure > how > they > >could detect whether or not you are running NAT but they might just > be > making > >an "educated" guess. > > That would be surprising, considering that I have no problem using > Linksys or D-Link routers (BEFSR41 & DI-614+ respectively). Unless > Shorewall implements NAT differently, thus allowing my ISP to detect > I > have a NAT set up?I would suspect that MTU size could be the issue here. I could be wrong. PPOE has an MTU of 1492 bytes versus the regular 1500 bytes. 1) On the machine running shorewall what does "ifconfig" show? Please paste that here. 2) On the shorewall machine what happens if you ping this ip with the following "ping" options set? banks@deadmeat etc $ ping -M do -s 1492 66.218.71.86 (the "-M do" says don''t fragement this packet. So what your trying to do here is find the largest size packet that you can send over your link with out it needing to be fragmented. In my example I have this set to "-s 1492" (this value is a good starting point for you) Keep adjusting this value lower until your pings go through. For ppoe this is usually around 1464-1472. Max mtu for ppoe is 1492 bytes -IP header of 20 bytes -ICMP header of 8 bytes. Right around in this ball park anyways. If you have Windows machines behind Shorewall then you can do. "ping -l 1492 -f 66.218.71.86" This is close to the same as the ping that you will do on shorewall. When you get disconnected what do you need to do to get reconnected again. Reboot the cable modem? There should be at a minimum some logs from shorewall showing something going on just before you get disconnected. If not then I would packet sniff with either Tcp dump or ethereal on an internal machine (when doing a long file transfer) and on the external facing nic card on Shorewall to get a better idea of whats happening. I suspect that mtu is an issue. But to blame Shorewall you will need to provide some evidence please. Every problem has a work around and with linux you should be able to work around just about any problem. I think you have an internal machine negotiating with an exteranl machine to send packets with the biggest mtu for efficiencey when doing the transfer and somehow they both don''t realize that they have a ppoe link that sits between them with an mtu that is lower than the standard 1500 byte mtu for ethernet. HTH''s, Joshua Banks __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
st1\:*{behavior:url(#default#ieooui) }
First, thanks for replying! :)
>1) On the machinerunning shorewall what does "ifconfig" show?
Please paste that here.
<-snip->
eth0 Link encap:Ethernet HWaddr 00:50:BA:58:CE:71
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4325591 errors:0 dropped:0 overruns:0 frame:0
TX packets:4977889 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1089964827 (1.0 GiB) TX bytes:801724905 (764.5 MiB)
Interrupt:5 Base address:0x8000
eth1 Link encap:Ethernet HWaddr 00:E0:29:40:AC:CD
inet addr:10.0.0.10 Bcast:10.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5573940 errors:0 dropped:0 overruns:0 frame:0
TX packets:4473516 errors:0 dropped:0 overruns:0 carrier:0
collisions:505 txqueuelen:100
RX bytes:998313445 (952.0 MiB) TX bytes:1085247657 (1.0 GiB)
Interrupt:10 Base address:0xc400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:371 errors:0 dropped:0 overruns:0 frame:0
TX packets:371 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:40932 (39.9 KiB) TX bytes:40932 (39.9 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:207.112.44.134 P-t-P:216.254.132.7 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:536286 errors:0 dropped:0 overruns:0 frame:0
TX packets:433616 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:465578166 (444.0 MiB) TX bytes:134154952 (127.9 MiB)
</-snip->
>2) On the shorewallmachine what happens if you ping this ip with the
following "ping"options set?
>
>banks@deadmeat etc $ping -M do -s 1492 66.218.71.86
I have to set the packetsize at 1464 or lower, same for Windows, to ping the
host.
>When you getdisconnected what do you need to do to get reconnected again.
Reboot the cablemodem?
To reestablish connection, Ihave to either wait until pppd restarts the
connection automatically, or restartit manually. No DSLmodem power cycling or
anything needs to be done...
>There should be at aminimum some logs from shorewall showing something going
on just before you
>get disconnected. If notthen I would packet sniff with either Tcp dump or
ethereal on an internal
>machine (when doing along file transfer) and on the external facing nic card
on Shorewall to get
>a better >idea ofwhats happening.
I will over the next 2-3days do some packet sniffing, and I#8217;ll try to get
someinteresting/relevant
Logs...
>I suspect that mtu is anissue. But to blame Shorewall you will need to
provide some evidence
>please. Every problemhas a work around and with linux you >should be able
to work around just
>aboutany problem.
>
>I think you have aninternal machine negotiating with an exteranl machine to
send packets with the
>biggest mtu forefficiencey when doing the transfer and somehow they both
don''t realize thatthey
>have a ppoe link thatsits between them with an mtu that is lower than the
standard 1500 byte mtu
>for ethernet.
I#8217;m not trying toblame Shorewall per say, just trying to figure out
what#8217;s going on. Up tonow, everything points to Shorewall, but it#8217;s
mainly circumstantialevidence :) The Max MTU set on my PPPoE connection (in
PPPoE config) is 1412,just in case. I tried with various numbers between 1412
and 1492, but to noavail.
---------------------------------
Post your free ad now! Yahoo! Canada Personals
--- Dominique Archambault <apox@yahoo.com> wrote:> st1\:*{behavior:url(#default#ieooui) }What is that stuff above. ICKY... :D> First, thanks for replying! :)No problem Dominique.> I have to set the packetsize at 1464 or lower, same for Windows, to > ping the host.Yes.. This was one of the base facts I was looking for. You have a max mtu of 1492 bytes. When you use ping with the options specified you told it to pad the data payload of the packet with 1492 bytes and not to fragment the packet in transit. Add an additional 20 bytes for the IP header and another additional 8 bytes for the ICMP header and your 28 bytes over your Max mtu of 1492. So your actual max (mss)or same as (your max data payload unfragemented) when sending ICMP is 1464 bytes. Or ICMP MSSMAX MTU -28 bytes. This will be the same when using applications that utilize UDP. When you have an application that is using TCP this will be MSS= MAX MTU -40 to -44 bytes. IP header =20 bytes TCP header =20 to 24 bytes. (the other 4 bytes are for TCP options). For you, max TCP mss unfragemented is 1448 bytes, or 1452 if no tcp options are used in the tcp header.> To reestablish connection, Ihave to either wait until pppd restarts > the connection automatically, or restartit manually. No DSLmodem > power cycling or anything needs to be done...And before shorewall was put in place to route/firewall/nat, you used a DLink router connected to the same cable modem?> I will over the next 2-3days do some packet sniffing, and I''ll > try to get some interesting/relevant Logs...This will help out allot.> I''m not trying to blame Shorewall per say, just trying to figure > out what''s going on. Up to now, everything points to Shorewall, > but it''s mainly circumstantial evidence :) The Max MTU set on my > PPPoE connection (in PPPoE config) is 1412,just in case. I tried with > various numbers between 1412 and 1492, but to noavail.I''m sorry. I didn''t mean to say you WERE blaming Shorewall. What I meant to say was, "To establish that Shorewall is the problem we need to gather so more solid facts." Dominique, if this is something (the problem that your describing), that you can replicate at will, then thats half the battle and makes trouble shooting allot easier believe it or not. E.G. on an internal windows machine install and start "ethereal" while doing one of your big file transfers that causes your problem. Install "ehtereal on the Shorewall machine and have it sniff off "ppp0" at the same time you doing the huge file transfer. Both ethereal captures along with the Shorewall logs and the info that your providing here in this post and the next should isolate where the problem is actually occurring. You said:>The Max MTU set on my PPPoE connection (in PPPoE config) is 1412,just >in case.I tried with various numbers between 1412 and 1492, but to >noavail.My response: Did you do this on the machine running Shorewall or a machine behind Shorewall? My recommendation is to set your mtu on a windows machine too a more than safe minimum of 1448 bytes. Turn on ethereal on this machine and the shorewall machine and start your big file transfer on this machine. (For adjusting MTU values on windows 9x machines I reccommend an app called Dr. Tcp.) Google it and you''ll find it. This way you don''t have to mess with the registry. This app does it for you on the fly. Make sure to read the documentation. There''s not much to read. I noticed that you had eth0 and eth1. Tell us a little more about your network please. I.E. which one is local and which is your Dmz? So is this something that you can replicate? If so then what kind of application are you using?Brand name please... to do what kind of file transfers? Ftp, smtp, http, tftp, telnet, rsync....(and for those, any particular flavor) apache, proftp, postfix, qmail sendmail..yada..yadd..yada.. ?? Are you uploading or downloading??. Is this using Tcp, Udp, Ipsec ect.. ect... And just to make sure I understand you correctly this is happening when internal clients are transferring big files to servers out on the EXteranl internet somewhere?? Not a server on the dmz or a server located on an internal WAN? Thanks, Joshua Banks __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
I forgot to append this to my previous response today: # # MSS CLAMPING # # Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU" # option. This option is most commonly required when your internet # interface is some variant of PPP (PPTP or PPPoE). Your kernel must # have CONFIG_IP_NF_TARGET_TCPMSS set. # # [From the kernel help: # # This option adds a `TCPMSS'' target, which allows you to alter the # MSS value of TCP SYN packets, to control the maximum size for that # connection (usually limiting it to your outgoing interface''s MTU # minus 40). # # This is used to overcome criminally braindead ISPs or servers which # block ICMP Fragmentation Needed packets. The symptoms of this # problem are that everything works fine from your Linux # firewall/router, but machines behind it can never exchange large # packets: # 1) Web browsers connect, then hang with no data received. # 2) Small mail works fine, but large emails hang. # 3) ssh works fine, but scp hangs after initial handshaking. # ] # # If left blank, or set to "No" or "no", the option is not enabled. # --- Joshua Banks <l0f33t@yahoo.com> wrote:> > --- Dominique Archambault <apox@yahoo.com> wrote: > > st1\:*{behavior:url(#default#ieooui) } > > What is that stuff above. ICKY... :D > > > First, thanks for replying! :) > > No problem Dominique. > > > > I have to set the packetsize at 1464 or lower, same for Windows, to > > ping the host. > > Yes.. This was one of the base facts I was looking for. You have a > max > mtu of 1492 bytes. > When you use ping with the options specified you told it to pad the > data payload of the packet with 1492 bytes and not to fragment the > packet in transit. Add an additional 20 bytes for the IP header and > another additional 8 bytes for the ICMP header and your 28 bytes over > your Max mtu of 1492. So your actual max (mss)or same as (your max > data > payload unfragemented) when sending ICMP is 1464 bytes. Or ICMP MSS> MAX MTU -28 bytes. This will be the same when using applications that > utilize UDP. > > When you have an application that is using TCP this will be MSS= MAX > MTU -40 to -44 bytes. IP header =20 bytes TCP header =20 to 24 bytes. > (the other 4 bytes are for TCP options). For you, max TCP mss > unfragemented is 1448 bytes, or 1452 if no tcp options are used in > the > tcp header. > > > > To reestablish connection, Ihave to either wait until pppd restarts > > the connection automatically, or restartit manually. No DSLmodem > > power cycling or anything needs to be done... > > And before shorewall was put in place to route/firewall/nat, you used > a > DLink router connected to the same cable modem? > > > > I will over the next 2-3days do some packet sniffing, and I''ll > > try to get some interesting/relevant Logs... > > This will help out allot. > > > I''m not trying to blame Shorewall per say, just trying to figure > > out what''s going on. Up to now, everything points to Shorewall, > > but it''s mainly circumstantial evidence :) The Max MTU set on my > > PPPoE connection (in PPPoE config) is 1412,just in case. I tried > with > > various numbers between 1412 and 1492, but to noavail. > > I''m sorry. I didn''t mean to say you WERE blaming Shorewall. What I > meant to say was, "To establish that Shorewall is the problem we need > to gather so more solid facts." > > Dominique, if this is something (the problem that your describing), > that you can replicate at will, then thats half the battle and makes > trouble shooting allot easier believe it or not. E.G. on an internal > windows machine install and start "ethereal" while doing one of your > big file transfers that causes your problem. > Install "ehtereal on the Shorewall machine and have it sniff off > "ppp0" > at the same time you doing the huge file transfer. > > Both ethereal captures along with the Shorewall logs and the info > that > your providing here in this post and the next should isolate where > the > problem is actually occurring. > > You said: > >The Max MTU set on my PPPoE connection (in PPPoE config) is > 1412,just > >in case.I tried with various numbers between 1412 and 1492, but to > >noavail. > > My response: > Did you do this on the machine running Shorewall or a machine behind > Shorewall? > > My recommendation is to set your mtu on a windows machine too a more > than safe minimum of 1448 bytes. Turn on ethereal on this machine and > the shorewall machine and start your big file transfer on this > machine. > (For adjusting MTU values on windows 9x machines I reccommend an app > called Dr. Tcp.) Google it and you''ll find it. This way you don''t > have > to mess with the registry. This app does it for you on the fly. Make > sure to read the documentation. There''s not much to read. > > I noticed that you had eth0 and eth1. Tell us a little more about > your > network please. I.E. which one is local and which is your Dmz? > > So is this something that you can replicate? > > If so then what kind of application are you using?Brand name > please... > to do what kind of file transfers? Ftp, smtp, http, tftp, telnet, > rsync....(and for those, any particular flavor) apache, proftp, > postfix, qmail sendmail..yada..yadd..yada.. ?? Are you uploading or > downloading??. Is this using Tcp, Udp, Ipsec ect.. ect... > > And just to make sure I understand you correctly this is happening > when > internal clients are transferring big files to servers out on the > EXteranl internet somewhere?? Not a server on the dmz or a server > located on an internal WAN? > > Thanks, > Joshua Banks > > __________________________________ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing. > http://photos.yahoo.com/ > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
After futher review I beleive that setting up your local machines with an MTU of 1492 bytes and making sure the below "CLAMPMSS=Yes" is set in "/etc/shorewall.conf", "Your kernel must # have CONFIG_IP_NF_TARGET_TCPMSS set as well", and this should do the trick. If it doesn''t then I beleive that you''ve done something on shorewall to not allow the needed "ICMP Fragmentation Needed" packets back to the clients. Either that or the ICMP packets are making it back but the client application that your running is ignoring them. But the fact that you claim that a DLink router and some other router didn''t give you any trouble. So I suspect shorewall configuration tweaks needed. If not then packet sniffs are going to definitely tell us whats happening. HTH''s, Joshua Banks --- Joshua Banks <l0f33t@yahoo.com> wrote:> I forgot to append this to my previous response today: > > # > # MSS CLAMPING > # > # Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS > to > PMTU" > # option. This option is most commonly required when your internet > # interface is some variant of PPP (PPTP or PPPoE). Your kernel must > # have CONFIG_IP_NF_TARGET_TCPMSS set. > # > # [From the kernel help: > # > # This option adds a `TCPMSS'' target, which allows you to alter > the > # MSS value of TCP SYN packets, to control the maximum size for > that > # connection (usually limiting it to your outgoing interface''s MTU > # minus 40). > # > # This is used to overcome criminally braindead ISPs or servers > which > # block ICMP Fragmentation Needed packets. The symptoms of this > # problem are that everything works fine from your Linux > # firewall/router, but machines behind it can never exchange large > # packets: > # 1) Web browsers connect, then hang with no data received. > # 2) Small mail works fine, but large emails hang. > # 3) ssh works fine, but scp hangs after initial handshaking. > # ] > # > # If left blank, or set to "No" or "no", the option is not enabled. > # > > --- Joshua Banks <l0f33t@yahoo.com> wrote: > > > > --- Dominique Archambault <apox@yahoo.com> wrote: > > > st1\:*{behavior:url(#default#ieooui) } > > > > What is that stuff above. ICKY... :D > > > > > First, thanks for replying! :) > > > > No problem Dominique. > > > > > > > I have to set the packetsize at 1464 or lower, same for Windows, > to > > > ping the host. > > > > Yes.. This was one of the base facts I was looking for. You have a > > max > > mtu of 1492 bytes. > > When you use ping with the options specified you told it to pad the > > data payload of the packet with 1492 bytes and not to fragment the > > packet in transit. Add an additional 20 bytes for the IP header and > > another additional 8 bytes for the ICMP header and your 28 bytes > over > > your Max mtu of 1492. So your actual max (mss)or same as (your max > > data > > payload unfragemented) when sending ICMP is 1464 bytes. Or ICMP > MSS> > MAX MTU -28 bytes. This will be the same when using applications > that > > utilize UDP. > > > > When you have an application that is using TCP this will be MSS> MAX > > MTU -40 to -44 bytes. IP header =20 bytes TCP header =20 to 24 > bytes. > > (the other 4 bytes are for TCP options). For you, max TCP mss > > unfragemented is 1448 bytes, or 1452 if no tcp options are used in > > the > > tcp header. > > > > > > > To reestablish connection, Ihave to either wait until pppd > restarts > > > the connection automatically, or restartit manually. No DSLmodem > > > power cycling or anything needs to be done... > > > > And before shorewall was put in place to route/firewall/nat, you > used > > a > > DLink router connected to the same cable modem? > > > > > > > I will over the next 2-3days do some packet sniffing, and I''ll > > > try to get some interesting/relevant Logs... > > > > This will help out allot. > > > > > I''m not trying to blame Shorewall per say, just trying to figure > > > out what''s going on. Up to now, everything points to Shorewall, > > > but it''s mainly circumstantial evidence :) The Max MTU set on my > > > PPPoE connection (in PPPoE config) is 1412,just in case. I tried > > with > > > various numbers between 1412 and 1492, but to noavail. > > > > I''m sorry. I didn''t mean to say you WERE blaming Shorewall. What I > > meant to say was, "To establish that Shorewall is the problem we > need > > to gather so more solid facts." > > > > Dominique, if this is something (the problem that your describing), > > that you can replicate at will, then thats half the battle and > makes > > trouble shooting allot easier believe it or not. E.G. on an > internal > > windows machine install and start "ethereal" while doing one of > your > > big file transfers that causes your problem. > > Install "ehtereal on the Shorewall machine and have it sniff off > > "ppp0" > > at the same time you doing the huge file transfer. > > > > Both ethereal captures along with the Shorewall logs and the info > > that > > your providing here in this post and the next should isolate where > > the > > problem is actually occurring. > > > > You said: > > >The Max MTU set on my PPPoE connection (in PPPoE config) is > > 1412,just > > >in case.I tried with various numbers between 1412 and 1492, but to > > >noavail. > > > > My response: > > Did you do this on the machine running Shorewall or a machine > behind > > Shorewall? > > > > My recommendation is to set your mtu on a windows machine too a > more > > than safe minimum of 1448 bytes. Turn on ethereal on this machine > and > > the shorewall machine and start your big file transfer on this > > machine. > > (For adjusting MTU values on windows 9x machines I reccommend an > app > > called Dr. Tcp.) Google it and you''ll find it. This way you don''t > > have > > to mess with the registry. This app does it for you on the fly. > Make > > sure to read the documentation. There''s not much to read. > > > > I noticed that you had eth0 and eth1. Tell us a little more about > > your > > network please. I.E. which one is local and which is your Dmz? > > > > So is this something that you can replicate? > > > > If so then what kind of application are you using?Brand name > > please... > > to do what kind of file transfers? Ftp, smtp, http, tftp, telnet, > > rsync....(and for those, any particular flavor) apache, proftp, > > postfix, qmail sendmail..yada..yadd..yada.. ?? Are you uploading or > > downloading??. Is this using Tcp, Udp, Ipsec ect.. ect... > > > > And just to make sure I understand you correctly this is happening > > when > > internal clients are transferring big files to servers out on the > > EXteranl internet somewhere?? Not a server on the dmz or a server > > located on an internal WAN? > > > > Thanks, > > Joshua Banks > > > > __________________________________ > > Do you Yahoo!? > > New Yahoo! Photos - easier uploading and sharing. > > http://photos.yahoo.com/ > > _______________________________________________ > > Shorewall-users mailing list > > Post: Shorewall-users@lists.shorewall.net > > Subscribe/Unsubscribe: > > https://lists.shorewall.net/mailman/listinfo/shorewall-users > > Support: http://www.shorewall.net/support.htm > > FAQ: http://www.shorewall.net/FAQ.htm > > > __________________________________ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing. > http://photos.yahoo.com/ > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/