Description of problem:
Using FC5 as Gateway enabling MASQ for LAN, I cannot browse http URls.
Version-Release number of selected component (if applicable):
From a box in a LAN with FC5 as Gateway browse
Steps to Reproduce:
2.Connect a box thru ethX (XP in my case)
3.Connect FC5 to internet (.i.e ueagle-atm module with pppd -ppd options as
described in your Fedora page for eagle-usb modems)
4.Use following iptable :
# Reset Default Policies
$IPT -P INPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT
# Flush all rules
$IPT -t nat -F
$IPT -t mangle -F
# Erase all non-default chains
$IPT -t nat -X
$IPT -t mangle -X
5. from box connected in step 2, browse this URL:
browser timing out.
I think you should use masquerading.
If I had not beeing using MASQ, how do you think that I can see this page. IN
fact I can see a lot of URLs in this machine using FC5 as Gateway, but NOT the
one I am reporting. I repeat that address.
http://www.hsbc.com.ar/hsbc_group_asp/pc_banking/pc_banking.asp(In reply to
Can you please perform these tests with a linux box in your network:
1) ping www.hsbc.com.ar
2) traceroute www.hsbc.com.ar
3) lynx http://www.hsbc.com.ar/hsbc_group_asp/pc_banking/pc_banking.asp
You wrote: "Use following iptable" and there is no masquerading rule in there.
(In reply to comment #3)
> Can you please perform these tests with a linux box in your network:
> 1) ping www.hsbc.com.ar
> 2) traceroute www.hsbc.com.ar
> 3) lynx http://www.hsbc.com.ar/hsbc_group_asp/pc_banking/pc_banking.asp
> You wrote: "Use following iptable" and there is no masquerading rule in there.
Sorry about misunderstanding, I tried to avoid all rules to trace the problem,
so please add to the previous rules the following:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o XXX -j MASQUERADE (where XXX = your interface)
Here are the results of tests (numbered in same order as yours)
Result of 1:
# ping www.hsbc.com.ar
PING www.hsbc.com.ar (22.214.171.124) 56(84) bytes of data.
--- www.hsbc.com.ar ping statistics ---
801 packets transmitted, 0 received, 100% packet loss, time 799957ms
Result of 2:
# traceroute www.hsbc.com.ar
traceroute to www.hsbc.com.ar (126.96.36.199), 30 hops max, 38 byte packets
1 pclinux (192.168.1.2) 0.266 ms 0.184 ms 0.308 ms
2 188.8.131.52 (184.108.40.206) 16.557 ms 12.484 ms 11.829 ms
3 192.168.99.234 (192.168.99.234) 11.851 ms 11.874 ms 11.952 ms
4 220.127.116.11 (18.104.22.168) 11.956 ms 11.895 ms 11.914 ms
5 22.214.171.124 (126.96.36.199) 11.981 ms 14.875 ms 14.962 ms
6 npcR06-tibR01-02775.metrored.net.ar (188.8.131.52) 62.939 ms 32.746 ms
7 host089201.metrored.net.ar (184.108.40.206) 56.773 ms 104.855 ms 131.919 ms
8 host129242.metrored.net.ar (220.127.116.11) 275.908 ms 159.089 ms 116.939 ms
9 * * *
10 * * *
Result of 3:
# rpm -i /media/cdrecorder/Fedora/RPMS/lynx-2.8.5-18.i386.rpm
# lynx http://www.hsbc.com.ar/hsbc_group_asp/pc_banking/pc_banking.asp
Making HTTPS connection to hbsrv.pcbanking.hsbc.com.ar
Comments about result 3: it hangs with the last message shown
General comments: this results are similar (without performing above tests), to
the ones performed on a XP box. (Hanging of page)
Your FC5 gateway seems to work, because the packages are going out - see the
Are you sure, that this is a problem with FC-5 only?
(In reply to comment #5)
> Are you sure, that this is a problem with FC-5 only?
Sorry, I dont have any other gateway to check. This problem appeared after Fc5
installation, and with different browsers as you can see, i.e. Lynx , Netscape ,
Firefox ,etc. Though I cannot browse from the LAN, I can still browse the
problematic URL from the gateway itself.
Do you have any FC5 Gateway to check all this?
Changing MTU on client machine solves the problem.
Description: on FC5 ueagle-usb driver is within distribution. This also changes
link configuration as from previous drivers. One of the changes is MTU size now
changed to 1492. As a result, some http flow hangs. I changed MTU on client
machine to 1454 (using DRTCP) and now I can browse those sites.