Topic: No longer able to access secure remote web sites

[allsorts]

Hi,

What controls the passing of packets on port 443 with SME7.0rc2?

I can no longer access *any* remote secure web sites. Using iptraf looking for packets destined for port 443 I can see them on the internal interface (and indeed secure access for local webmail works) but any outgoing packets never appear on the external interface. If I  look at say port 80 I can see those internally and externally.

This is under diald and an ISDN connection, it did work the last time I had to use it... I have been trying to sort out an issue with diald related to the naming of services in /etc/services and diald.filter but I have taken those diald.filter custom template changes out (and run signal-event post-upgrade/reboot) but with no effect on this remote secure access problem.

Cheers
Dave.

[allsorts]

Well I've found the masq/iptables does the firewalling stuff but if I enable tracing (config setprop masq Trace enable) and restart the server it doesn't look like masq/iptables is dropping/denying the port 443 packets as I get sections like this when doing "grep DPT=443 /var/log/messages":

May 28 12:31:34 srv1 kernel: *m:PREROUTING:-:ACCEPT:IN=eth0 OUT=
MAC=00:08:c7:07:b8:23:00:48:54:8f:3d:6e:08:00 SRC=192.168.0.34 DST=66.135.214.195
LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=35281 PROTO=TCP SPT=3160 DPT=443 WINDOW=28672
RES=0x00 SYN URGP=0

May 28 12:31:34 srv1 kernel: *m:FORWARD:-:ACCEPT:IN=eth0 OUT=ippp0 SRC=192.168.0.34 DST=66.135.214.195
LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=35281 PROTO=TCP SPT=3160 DPT=443 WINDOW=28672
RES=0x00 SYN URGP=0

May 28 12:31:34 srv1 kernel: *f:FORWARD:1:state_chk:IN=eth0 OUT=ippp0 SRC=192.168.0.34 DST=66.135.214.195
LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=35281 PROTO=TCP SPT=3160 DPT=443 WINDOW=28672
RES=0x00 SYN URGP=0

May 28 12:31:34 srv1 kernel: *f:FORWARD:3:local_chk:IN=eth0 OUT=ippp0 SRC=192.168.0.34 DST=66.135.214.195
LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=35281 PROTO=TCP SPT=3160 DPT=443 WINDOW=28672
RES=0x00 SYN URGP=0

May 28 12:31:34 srv1 kernel: *f:local_chk:1:local_chk_382:
IN=eth0 OUT=ippp0 SRC=192.168.0.34 DST=66.135.214.195 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=35281
PROTO=TCP SPT=3160 DPT=443 WINDOW=28672
RES=0x00 SYN URGP=0

May 28 12:31:34 srv1 kernel: *f:local_chk_3822:3:ACCEPT:IN=eth0 OUT=ippp0
SRC=192.168.0.34 DST=66.135.214.195 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=35281 PROTO=TCP SPT=3160 DPT=443 WINDOW=28672 RES=0x00 SYN URGP=0

May 28 12:31:34 srv1 kernel: *m:POSTROUTING:-:ACCEPT:
IN= OUT=ippp0 SRC=192.168.0.34 DST=66.135.214.195 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=35281 PROTO=TCP SPT=3160 DPT=443 WINDOW=28672
RES=0x00 SYN URGP=0

No sign of "deny" or "drop" anywhere.  B-((

I've tried changing the diald settings so that the link is up all the time, no difference, still can't get to any secure sites. Mail, news ftp, ordinary web browsing are all working fine.

[CharlieBrady]

Please report all details about any possible bug via the Bug Tracker (as I know you have been told many times). Thanks.

[allsorts]

I will when I have something more than "it doesn't work" to report. At the moment I don't think there is a bug with SME. Two reasons, no logging of denied or droped packets and I've just found one machine of the three on the local LAN *can* access secure pages.

Of the three machines two are running Win2k with all the latest updates etc. One can access secure pages the other can't. By dint of editing the registry on one and removing the /var/lib/dhcp/dhcpd.leases on SME I've swapped the IP address's of those machines. The abilty to access secure pages has stayed with the machine, not moved with the IP address.

The third machine I can boot to OS/2 Warp 3, Win2k or Suse Linux 10.0, no matter what OS it is running it can't access secure pages. Under Win2k it gets a DHCP allocated address, under OS/2 or Linux it has a static IP address outside the SME DHCP range.

In between all this everything has been power cycled, all off at the same time, including the 8 port switch that connects the local LAN.

I'm just asking for ideas of where to look, 'cause I'm pretty much stumped now, short of ripping open machines and moving NICs about...

Cheers
Dave.