So you've tried accessing through the masq and then the proxy from the same
client?

Some other things I can think of trying:

- Any other sites have this problem? Or just ge?
- How about ftp?
- Are you redirecting the http requests? Could you try not redirecting?
- How about stopping the proxy server, then try your masq test. Maybe there is
some conflict there.
- Are there any errors reported by "netstat -i" on the nic?

Michael Kohne wrote:

> I've got a newly installed RedHat 5.0 system and I've setup IP masquerading on
> it.
> The problem is that with http access (this is our primary use of the link)
> some
> client machines will experience problems where where the web access goes on,
> but becomes extremely slow. From my machine (192.168.0.5), for instance, I try
> to access <http://www.ge.com/>www.ge.com. The web page WILL eventually come
> up,
> but it can take an extreme amount of time (30 minutes) to do so. Running
> netscape on the link machine (X server running on 192.168.0.5)
> <http://www.ge.com/>www.ge.com pops up nearly instantly. Other local client
> machines don't seem to have any trouble. Accessing the web from my machine,
> using the link machine as a proxy server doesn't seem to have any problems.
>
> Doing an ipfwadm -M -l -e on the server while my machine is loading www.ge.com
> gives the following:
> IP masquerading entries
> prot expire      initseq delta prevd source               destination
> ports
> tcp  14:57.58          0     0     0 192.168.0.5          192.35.39.40
> 1437 (61157) -> 80
>
> Here's my configuration:
> Link machine is doing dial-up to our local ISP and taking the address our ISP
> gives it. (ppp0 interface)
> Link machine contains an ethernet card and is connected to our local lan (eth0
> interface, link machine is 192.168.0.7)
> local network is 192.168.0.X (Is this OK?)
> Kernel is stock redhat 5.0 kernel (2.0.32)
> networking section of the stock kernel config:
> #
> # Networking options
> #
> CONFIG_FIREWALL=y
> CONFIG_NET_ALIAS=y
> CONFIG_INET=y
> CONFIG_IP_FORWARD=y
> CONFIG_IP_MULTICAST=y
> CONFIG_SYN_COOKIES=y
> # CONFIG_RST_COOKIES is not set
> CONFIG_IP_FIREWALL=y
> CONFIG_IP_FIREWALL_VERBOSE=y
> CONFIG_IP_MASQUERADE=y
> #
> # Protocol-specific masquerading support will be built as modules.
> #
> # CONFIG_IP_MASQUERADE_IPAUTOFW is not set
> CONFIG_IP_MASQUERADE_ICMP=y
> CONFIG_IP_TRANSPARENT_PROXY=y
> # CONFIG_IP_ALWAYS_DEFRAG is not set
> CONFIG_IP_ACCT=y
> # CONFIG_IP_ROUTER is not set
> CONFIG_NET_IPIP=m
> # CONFIG_IP_MROUTE is not set
> CONFIG_IP_ALIAS=m
> #
> # (it is safe to leave these untouched)
> #
> # CONFIG_INET_PCTCP is not set
> CONFIG_INET_RARP=m
> # CONFIG_NO_PATH_MTU_DISCOVERY is not set
> CONFIG_IP_NOSR=y
> CONFIG_SKB_LARGE=y
>
> This set of options looks OK to me from looking at the FAQs, but I could be
> wrong.
> ipfwadm -I -l -e:
> IP firewall input rules, default policy: deny
>  pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source
> destination          ports
>  1308  121K acc   all  ---- 0xFF 0x00 eth0    any             192.168.0.0/24
> anywhere             n/a
>     0     0 deny  all  ---o 0xFF 0x00 ppp0    any             192.168.0.0/24
> anywhere             n/a
>    12  2994 acc   all  ---- 0xFF 0x00 ppp0    any             anywhere
> anywhere             n/a
>     9  1506 acc   all  ---- 0xFF 0x00 lo      any             anywhere
> anywhere             n/a
>     0     0 deny  all  ---o 0xFF 0x00 any     any             anywhere
> anywhere             n/a
>
> ipfwadm -O -l -e:
> IP firewall output rules, default policy: accept
>
> ipfwadm -F -l -e:
> IP firewall forward rules, default policy: deny
>  pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source
> destination          ports
>   132 10106 acc/m all  ---- 0xFF 0x00 ppp0    any             192.168.0.0/24
> anywhere             n/a
>     0     0 deny  all  ---o 0xFF 0x00 any     any             anywhere
> anywhere             n/a
>
> Now:
> If anyone can tell me what I'm doing wrong, I'd love to know.
> If anyone can tell me what to do as my next debugging step, I'd love to hear
> it.
>
> If I don't hear anything else, I'll probably try upgrading to the 2.0.33
> kernel
> as my next step, but if I can avoid that, I'd like to.
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> For daily digest info, email [EMAIL PROTECTED]



--
Larry Cannell
[EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]

Reply via email to