Hi Tim, thanks for the answer and your effort to help me. I finally gave up. Now i'm using ubuntu6.10 server with iptables and pppoe. Everything works perfectly for every client in every operating system. Still the same server is using the same hardware in the same network.
Not using pfsense is the only solution which works for me. Regards, Richard Am Montag, den 19.02.2007, 15:34 -0500 schrieb Tim Allender: > Richard wrote: > > Hello, > > > > thanks for your answer. > > > > > > > You can ping or traceroute snort.org all day long from anywhere in the > > > world and your not going to get through. > > > 63.240.198.67 (where you stop) is your first hop in the SourceFire > > > network. And, they don't pass ICMP traffic. > > > > > > > I know, my "can not reach snort.org" was realted to www though a > > browser. > > > > > > > You have verified that an MTU of 1500 is too large for your pppoe > > > connection. > > > So, verify that you have set the MTU for all interfaces (the router > > > lan/wan and all the boxes in question) to 1400. > > > > > > > > The largest frame "on the wire" in your dumps is 1214. I don't know > why, you've indicated you'd set 1300 on your client host and 1400 on > your pfsense box. > Try dropping them all down to MTU 1200. > > Okay, i changed every interface who is involved: > > > > Client: > > > > [EMAIL PROTECTED]:~$ ifconfig eth0 > > eth0 Protokoll:Ethernet Hardware Adresse 00:C0:9F:30:37:EF > > inet Adresse:192.168.150.50 Bcast:192.168.150.255 > > UP BROADCAST RUNNING MULTICAST MTU:1300 Metric:1 > > > > Firewall: > > > > (extern) > > > > xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1400 > > > > (pppoe) > > > > ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1400 > > inet6 fe80::20b:6aff:fe85:1745%ng0 prefixlen 64 scopeid 0xa > > inet 212.51.25.1 --> 212.51.31.92 netmask 0xffffffff > > > > (intern) > > > > dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1400 > > options=8<VLAN_MTU> > > inet 192.168.150.254 netmask 0xffffff00 broadcast192.168.150.255 > > media: Ethernet autoselect (100baseTX <full-duplex>) > > status: active > > > > > > > > > If you're still not getting the web page in your browser, verify the MTU > > > on both interfaces of the router, start full content dumps on both your > > > wan and lan ports, go to one of the afflicted hosts and verify MTU on > > > it's interface. > > > > > > > I did, as you can see in the ifconfig quoted above. > > Please find attached tcpdumps from intern extern and pppoe interfaces. > > > > > > > Establish the telnet connection, like before: > > > > > > > [EMAIL PROTECTED]:~$ telnet snort.org 80 > > Trying 199.107.65.177... > > Connected to snort.org. > > Escape character is '^]'. > > GET / HTTP/1.1 > > > > HTTP/1.1 400 Bad Request > > Date: Sat, 17 Feb 2007 16:09:41 GMT > > Server: Apache > > Content-Length: 226 > > Connection: close > > Content-Type: text/html; charset=iso-8859-1 > > > > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > > <html><head> > > <title>400 Bad Request</title> > > </head><body> > > <h1>Bad Request</h1> > > <p>Your browser sent a request that this server could not > > understand.<br /> > > </p> > > </body></html> > > Connection closed by foreign host. > > [EMAIL PROTECTED]:~$ > > > > (note i did copy your GET command and did hit enter twice) > > > > > > > (Note that you hit enter twice, an empty newline transmits). > > > Make a note of the response. > > > > > > > > By the way, note that, sites that have virtual hosts setup also > require you specify the host, like so: > GET / HTTP/1.1 > Host: snort.org > > That's the reason for your error here. > > > From your dumps, on the wan side dump, single out all snort.org > > > traffic; on the lan side dump, single out all traffic to/from the host > > > you were using. > > > Post those dumps. > > > > > > > Dumps from all interfaces are attached. > > > > I'm really looking forward to your next mail. > > Thanks a lot for taking the time! > > > > > Your dumps are not full content: "Packet size limited during transfer: > HTTP Truncated". Which means, what? Besides the fact that we can't > visually verify expected server responses, there are no tcp checksums > available for frames larger than 96 bytes, which could indicate a > faulty NIC somewhere, or other problems. But, no big deal. > > Besides that, you obviously have some issues. > I'm not so familiar with pppoe these days. It's been years since I had > to deal with it. However, I see your pppoe frames are 10 bytes smaller > than the ethernet frames. > I guess that's normal (null header 4 bytes, ethernet 14, 14-4=10). So > it doesn't look like anythings getting lost there. > Ultimately, your side is resetting the sessions, getting lots of > duplicate acks and crap. So... ya gotta try something. > > Have you tried doing what Scott suggested to you? > Start with an MTU of 500 and see if that works, first. And then start > raising it until it doesn't. Find the threshold. And then set it to > the largest MTU that works. > Since your largest pppoe frames are 1204, I would think your looking > for 1200. But, play around with it and see what happens. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
