I've recently had broadband installed. I'm using a Netgear DG834G router,
with one ethernet connection active to test it, to a PC running RH9.

It does http just fine, but won't do https. I've tried various sites
(my bank, dabs.co.uk, grc.com), no joy. I've tried various browsers
(listed below), no joy...

I borrowed a Solwise router from work (not recommended for Linux, BTW,
couldn't talk to it using Opera, Firefox, or an old Netscape, just one
verion of Mozilla), and once set up it worked fine for http and https

Netgear support ran through the firewall settings, tried adding a specific
rule to pass ports 443-447, and every option of MTU from the supplied
1458 down to 900 in steps (1458,1400,1358 etc), no joy.

They then escalated my problem to the UK support people, who have said
"Set the MTU to 1400, that will fix it"...

I've got the original configuration, with two extra firewall rules, same
as the defaults in each direction, but set to log as well, and changed
the local IP range to 192.168.35.x from 192.168.0.x

If I request an https page, a packet goes out, nothing else appears in
the log, and the browser eventually times out.

Does anyone have any ideas on how to investigate or fix it?

Nigel

In uk.telecom.broadband Nigel Orr <nigel@axoninstruments_dot_co.uk> wrote:
: I've recently had broadband installed. I'm using a Netgear DG834G router,
: with one ethernet connection active to test it, to a PC running RH9.

: It does http just fine, but won't do https. I've tried various sites
: (my bank, dabs.co.uk, grc.com), no joy. I've tried various browsers
: (listed below), no joy...

I wish people would not make definitive statements like this! OF COURSE it
CAN do https!!! There would have been an huge outcry long before now
if it could not!

On 19 Jan 2005 12:32:40 GMT, Nigel Orr <nigel@axoninstruments_dot_co.uk>
wrote:


Do a tcpdump on the interface and see if the 3 way handshake is being
completed.

use curl -I https://some.ssl.url/


to generate the traffic.



greg

--
Yeah - straight from the top of my dome
As I rock, rock, rock, rock, rock the microphone

Suggest that you remove the additional "logging" rules that you
have added to the firewall config.

Adding an "allow all with logging added" rule
causes the same effect on my non G version of this router.

I struggled with this a while ago

Nigel Orr <nigel@axoninstruments_dot_co.uk> writes:

Off topic, I know, but what does your router have to do with which
browser you use? All browsers send and receive the same rubbish down the
line at the end of the day. For that matter, I can't see what the router
has to do with the difference between http and https either... by the
time this information reaches the router it's all just TCP anyway. I
suppose if you had a firewall blocking OUTgoing connections on a
specific port you might have a problem, but imho firewalling traffic
going in that direction is a bit overkill for a home setup. I'm afraid
I'm not an expert in networky stuff so I can't really help you.

~ Rich

--
___
{o,o} ~ Rich <http://owl.me.uk/>
/) ) rich@owl.me.uk
-"-"- Jabber: owl@jabber.spodzone.org.uk

"Nigel Orr" <nigel@axoninstruments_dot_co.uk> wrote in message
news:41ee5368$0$69449$ed2619ec@ptn-nntp-reader03.plus.net...
If you running firmware > 1.03 then I think you might need to remove the
logging version of the default rules. I added a "copy" of the default rules
(except with logging enabled) on my DG834G's when I first had them (at v1.03
firmware) and they worked fine. However, for whatever reason when upgraded
to higher firmware versions this causes unexpected problems (I know not
why).

I'm currently running v1.05 firmware and it works fine, unless I add the
"copy" default rules with logging enabled when odd things stop working.

David

In article <87651ttsg9.fsf@sonar.owl.me.uk>, Rich Daley
<rich@DELETE_THISowl.me.uk> writes
I think he means that the web interface used to set up the router
struggles with some browsers. I use a Solwise 715 router and the setup
works with any browser that I have tried.

--
Russell Jepson

I think I has better clarify my own response
as it's a bit misleading / wrong !

Adding the following rule to the firewall :

"Inbound - Block all - Logging enabled"

could be assumed to clone the default inbound rule and
just add logging.

Well, it dosent ( on mine at least )
It does, however, cause interesting side effects.
On my 834, one being the sudden failure of https connections...

The bottom line is don't ( visually ) clone the default firewall rules and
just "add logging", because there are other side effects in doing this ....



"jon" <j_alight@REMOVEME.hotmail.com> wrote in message
news:TIOdnaPfA_1n-3PcRVnyvw@pipex.net...

"jon" <j_alight@REMOVEME.hotmail.com> wrote in message
news:lOmdnRho75yfHnPcRVnysA@pipex.net...

Yes I have exactly the same experience (except on v1.03 firmware, which
treated the cloned the default rule with logging as you would expect it to -
ie. it worked). I'd assumed that this not working as expected was a bug.
However, the way you've phrased your post sounds like you might understand
why this doesn't do what you might expect - do you have further information?

Thanks, David

"David" <mail@home.net> wrote in message
news:41ee84b4$0$26951$ed2619ec@ptn-nntp-reader01.plus.net...
I dont have any further info, really, other than a response from netgear
support
(to my query of this functionality) that stated ( in summary ) that
"You have introduced a new firewall rule to block inbound, so what is wrong
?"
In a perverse way, it sort of made sense, but then again....

I assumed that in attempting to clone the default rule ( in order to just
add logging) , I had unintentionally reconfigured the stateful
packet inspection firewall in such a way that affected certain ports numbers
(https, ftp for example). whereas standard web browsing (on port 80) still
worked fine. Very strange - to me at least...

Whether its a feature or a bug ? I really don't know

However, I must say that the router appears to log most, if not all,
unsolicited
inbound packets anyway, if you enable the
"Include in Log - Known DoS attacks and Port Scans"
in the "Logs" options page, so it's not really a problem to me.

It just can trip you up a bit, as you really don't expect certain services
to be blocked
when you think that all you have done is added logging

But this is a small aside on what has, for me, been a rock solid bit of
kit.....

Nigel Orr wrote:

had no problems with secure connections. I assume you have tried various
firmware versions (downgrade and upgrade). I am on long reach and had many
problems with DNS errors, hence I gave it to somebody else on normal
broadband who has no problems. The cheapo Safecom routers from ebuyer are
good value and work well if you are on long reach.

The safecom is a good computer board if you need a StrongArm with
ethernet,serial, wireless, and usb for under £60. I'll have to see if I
can put my own firmware in it!

Billy

On Wed, 19 Jan 2005 12:32:40 +0000, Nigel Orr wrote:

I've got a netgear dg834g and it's working fine. The only problem I had
was getting the VPN to work working - and guess what, I had to change the
MTU to fix it! That was on the pptpconfig program I was using - the eth0
MTU is still set to 1500.

I didn't have to do anything to the firewall, just leave it on NAT, no
extra firewall rules.

Have you got any proxying set up in your browser? I am using Firefox, and
just set it up with "Direct Connection to the Internet", no proxy set.

All I did apart from that was set up eth0 to use DHCP, obtain DNS from
DHCP, and "it all just worked".

On the router, I set it up with NAT. I upgraded the firmware to 1.0.5,
because it seemed like a good idea :-)

The MTU is set to 1458 in the WAN setup page - I can't remember if I
changed it, of if that was the default.

I turned on UPnP because it made bittorrent clients work without setting
up a firewall rule, but everything was working before I put that on.

I have a static IP address, and have disabled Dynamic DNS. I hope this
helps,

regards
Alan


--
Alan Fitch
reverse these words: org dot ieee at apfitch

Nigel Orr <nigel@axoninstruments_dot_co.uk> wrote:

AFAIK setting the MTU to 1400 for https to fix the problem is specific to
the combination of this router and AOL if they are your broadband ISP.
Certainly fixed the problem for an AOL using colleague of mine who has the
same kit and had the same symptoms as yourself.

Don't know if the same may apply to other ISPs.

MickB

In article <41ee80e9$0$14620$ed2619ec@ptn-nntp-reader01.plus.net>, David wrote:
I thought that I made it clear from the above that I realised it was the
router configuration, not the router, that I suspected was at fault. It's
not the only DG834 I use, and I know they _can_ do https!

Yes, I do mean the configuration interface was very browser-fussy. Model
number was SAR106 IIRC, it came with our work plus.net connection, and
was quickly replaced with a netgear there- now I know why :-)

And, as it turns out, they were right, but I told them about my extra
firewall rules and they reassured me they would be fine.

Absolutely right- thanks David and Jon for the answer. The problem had
originally been because MTU was set to 1458, then I had added the extra
rules to try to figure it out- https works perfectly now, with MTU set
to 1400 and the extra rules removed.

Nice to know that even with an almost 1:1 helpful:troll ratio uk.t.b
can come up with the goods :-)

Thanks for the helpful responses,

Nigel

Hi Nigel,

I had similar problems under windoze (I had a software firewall
running) and found that if I allowed a class 2 ping from the router,
all was fine.

Andy


Nigel Orr <nigel@axoninstruments_dot_co.uk> wrote in message news:<41ee5368$0$69449$ed2619ec@ptn-nntp-reader03.plus.net>...

"Mick Bernatek" <mick@esml.com> wrote in message
news:ciotu0ln3ec627pkeb75t57qtc9dqf5e1l@4ax.com...
Just to say, I had a similar problem where https wouldn't work, traced it
back to Norton Internet Security - try "fiddling" with your software
firewall too. I say "fiddle" cos I cannot remember how I fixed it! It was
about six months ago...