I've been working on this for several days now and am
getting nowhere. Below are two posts I made to
comp.os.linux.networking. The problem, in a nutshell,
is that all of my masqed hosts are unable to access
some, but not all, HTTPS sites, that are reachable
directly from the masqing host.
It's probably worth noting that the same setup was
working fine before I replaced my Slackware 2.0.22
setup with RH 5.2. (2.0.36)
Any help would be greatly appreciated.
Mike Ellis
Principal
Frogwing Associates
---------------------- first post -----------------------------
SYSTEM:
Small network of Linux (RH 5.2) and Windows boxes.
Internet connection through ppp0 on one of the
Linux boxes. This box's hostname is austin.
Domain is frogwing.com
ppp0 has static IP from ISP
eth0 = 192.168.1.1
Other boxes obtain 192.168.1.X IP's from austin's
dhcpd. Austin is running ip_masq as described in
the how-to. Austin is also the domain nameserver.
PROBLEM:
Other boxes are unable to access certain websites,
especially HTTPS, but also a few HTTP sites
(www.compaq.com is one).
Problem is common to both Netscape on Linux and
IE4 on Win95. Problem does not occur with Netscape
run on directly austin.
MORE INFORMATION:
Here are the ipfwadm rules from rc.local
ipfwadm -F f
ipfwadm -F -p deny
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
As a diagnostic effort I tried changing the default
forwarding policy from deny to accept, but it
had no impact.
All other clients are working correctly from
all boxes, telnet, ftp, mail, dns, icmp ...
Before installing RH 5.2, Austin was running
Slackware (2.0.22) with a similar setup, except
no DHCP. All clients browsed with zero problems.
I'm stumped. Any ideas?
Thanks
Mike Ellis
-------------------- followup post -------------------------
BACKGROUND
In my previous post, I described a problem accessing
HTTPS sites from ip_masq'd workstations. After receiving
David's suggestion to check port 443 permissions
I made some tests with tcpdump to attempt to see
if that was indeed the problem.
RESULTS
Using tcpdump shows that traffic on port 443 is flowing
in both directions. Seems to confirm that ipfw is
properly passing and routing packets on this port.
I'm not familiar enough with tcpdump to draw further
conclusions. Hopefully someone in the newsgroup will be
able to glean more than I have or suggest further diagnosis.
Also note that not all HTTPS sites are inaccessible. Makes
me suspect that there is something else going on. Netscape's
definition of SSL mentions an optional authentication
phase, but offers no further info.
I really need to allow folks behind the firewall to access
these sites, esp cheaptickets.com. Any help greatly
appreciated.
NAMES IN TCPDUMP OUTPUT
austin -- RH 5.2, connected to ISP through ppp0.
connect to lan through eth0
ipfwadm policies:
input accept
output accept
forward accept all, mask S 192.168.1.0/24 D 0.0.0.0/0
toad -- RH 5.2 connected to lan through eth0
IP = 192.168.1.32
dps1.lowfare.cheaptickets.com -- HTTPS server
reachable from austin, not from toad
amazon.com -- HTTPS server
reachable from both machines
DIAGNOSTIC METHOD
Set up terminal sessions on austin and toad. Invoke
tcpdump on both machines to capture packets on HTTPS port.
Use netscape to connect to secure server sites.
TCPDUMP OUTPUT
Below are tcpdump outputs for 3 different https connection events.
In #1, a successful direct connection from austin to
dps1.lowfare.cheaptickets.com is shown.
In #2a and #2b, a failed connection to the same site is shown
as seen by toad and austin. The connection was initiated by
toad.
In #3a and #3b, a good connection from toad to amazon.com's
secure server is shown.
In all cases, tcpdump was monitoring port 443. On austin
it listened to interface ppp0, on toad to eth0.
1. AUSTIN'S VIEW -- DIRECT CONNECTION
austin.3821 > dps1.lowfare.cheaptickets.com.443: S
3405083092:3405083092(0)
win 512 <mss 256>
dps1.lowfare.cheaptickets.com.443 > austin.3821: S
2386542671:2386542671(0)
ack 3405083093 win 49152 <mss 1460>
austin.3821 > dps1.lowfare.cheaptickets.com.443: . ack 1 win 32512 (DF)
austin.3821 > dps1.lowfare.cheaptickets.com.443: P 1:85(84) ack 1 win
32512
(DF)
dps1.lowfare.cheaptickets.com.443 > austin.3821: P 1:80(79) ack 85 win
49152
austin.3821 > dps1.lowfare.cheaptickets.com.443: . ack 80 win 32512 (DF)
dps1.lowfare.cheaptickets.com.443 > austin.3821: P 80:147(67) ack 85 win
49152
austin.3821 > dps1.lowfare.cheaptickets.com.443: . ack 147 win 32512
(DF)
austin.3821 > dps1.lowfare.cheaptickets.com.443: P 85:91(6) ack 147 win
32512 (DF)
austin.3821 > dps1.lowfare.cheaptickets.com.443: P 91:347(256) ack 147
win
32512 (DF)
2a. TOAD'S VIEW -- FAILED CONNECTION
192.168.1.32.1054 > dps1.lowfare.cheaptickets.com.443: S
2259323080:2259323080(0) win 512 <mss 1460>
dps1.lowfare.cheaptickets.com.443 > 192.168.1.32.1054: S
1131491749:1131491749(0) ack 2259323081 win 49152 <mss 1460> (DF)
192.168.1.32.1054 > dps1.lowfare.cheaptickets.com.443: . ack 1 win 32120
(DF)
192.168.1.32.1054 > dps1.lowfare.cheaptickets.com.443: P 1:40(39) ack 1
win
32120 (DF)
192.168.1.32.1054 > dps1.lowfare.cheaptickets.com.443: P 1:40(39) ack 1
win
32120 (DF)
dps1.lowfare.cheaptickets.com.443 > 192.168.1.32.1054: . ack 40 win
49152
(DF)
2b. AUSTIN"S VIEW -- FAILED CONNECTION
austin.61416 > dps1.lowfare.cheaptickets.com.443: S
2259323080:2259323080(0)
win 512 <mss 1460>
dps1.lowfare.cheaptickets.com.443 > 192.168.1.32.1054: S
1131491749:1131491749(0) ack 2259323081 win 49152 <mss 1460> (DF)
austin.61416 > dps1.lowfare.cheaptickets.com.443: . ack 1131491750 win
32120
(DF)
austin.61416 > dps1.lowfare.cheaptickets.com.443: P 0:39(39) ack 1 win
32120
(DF)
austin.61416 > dps1.lowfare.cheaptickets.com.443: P 0:39(39) ack 1 win
32120
(DF)
dps1.lowfare.cheaptickets.com.443 > 192.168.1.32.1054: . ack 40 win
49152
(DF)
3a. TOAD'S VIEW -- GOOD CONNECTION
192.168.1.32.1556 > amazon.com.443: S 738472094:738472094(0) win 512
<mss
256>
amazon.com.443 > 192.168.1.32.1556: S 1177073207:1177073207(0) ack
738472095
win 32768 <mss 1460> (DF)
192.168.1.32.1556 > amazon.com.443: . ack 1 win 32512 (DF)
192.168.1.32.1556 > amazon.com.443: P 1:40(39) ack 1 win 32512 (DF)
amazon.com.443 > 192.168.1.32.1556: . 257:513(256) ack 40 win 32768 (DF)
192.168.1.32.1556 > amazon.com.443: . ack 1 win 32512 (DF)
3b. AUSTIN'S VIEW -- GOOD CONNECTION
austin.1693 > k.gtld-servers.net.domain: 44561 A? ns2.pnap.NET. (30)
austin.61484 > amazon.com.443: S 738472094:738472094(0) win 512 <mss
256>
austin.61485 > zork.tiac.net.domain: 34176+ (43)
austin.1693 > NS.NASA.GOV.domain: 44562 (42)
amazon.com.443 > 192.168.1.32.1556: S 1177073207:1177073207(0) ack
738472095
win 32768 <mss 1460> (DF)
austin.61484 > amazon.com.443: . ack 1177073208 win 32512 (DF)
---- end ----
David K. Means wrote in message ...
>
>Mike Ellis <[EMAIL PROTECTED]> wrote in message
>news:7est9i$[EMAIL PROTECTED]...
>> [...]
>> Other boxes obtain 192.168.1.X IP's from austin's
>> dhcpd. Austin is running ip_masq as described in
>> the how-to. Austin is also the domain nameserver.
>>
>> PROBLEM:
>> Other boxes are unable to access certain websites,
>> especially HTTPS, but also a few HTTP sites
>> (www.compaq.com is one).
>>
>> Problem is common to both Netscape on Linux and
>> IE4 on Win95. Problem does not occur with Netscape
>> run on directly austin.
>>
> HTTPS uses a separate TCP port from `normal' HTTP. You'll need
>to allow traffic on port 443 (it should be called https in
/etc/services)
in
>both directions. If you'd like a little extra security, you can
require
>that
>incoming HTTPS packets have the ACK bit set ( -k switch for ipfwadm).
>
> Good luck.
>
>
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
http://tiffany.indyramp.com/mailman/listinfo/masq
Admin requests can be handled by web (above) or [EMAIL PROTECTED]
