dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
6
share rss forum feed

phardacre

join:2004-01-19
UK
reply to stoz

Re: [Config] Setup Cisco 877 to work with Bt Infinity

Hi Stoz,

That's cool, just wanted to check :) Only thing I can see at first glance is that you have GRE in access-list 101 which is used by your sdm-nat-smtp-1 rule. I would have expected it be in access-list 103 for the sdm-nat-pptp-1 rule. But I wouldn't expect that to stop a tcp connection to 1723 unless there's something in the PPTP inspect that blocks telnet connections (i.e. it's blocking the connection 'cos it knows it's not a PPTP client).

Can you try with a real PPTP client? As nmap/ShieldsUp see it as open, it might just work :)

The realserver/rtsp ports are likely included in the match protocol realmedia and match protocol rtsp as they're probably UDP and as such need to be allowed through but will get inspected to ensure they're valid.

Cheers,

Paul


stoz

join:2012-03-13

1 edit

Yeah no worries, I know from experience it's vital to start with the basics

I've tried to VPN in from our webserver as well as attempting the telnet, no luck either. I'll keep looking into it, fortunately it's not immediately urgent.

In fact it has just been overtaken in priority though by the fact that downloads simply do not work! I've done ping -l -f to work out that our max packet size is 1436, so I've tried setting 'ip mtu 1436' accordingly, as well as varying 'ip tcp adjust-mss' values. This is pretty crucial, and I'm trying to fix it before anyone notices, but obviously we need downloads working ASAP!

EDIT: the reason I'm not having any luck is probably because our web server doesn't have 1723 open, for inbound, and doesn't let anything out through that port either (this always confused me because I thought that source port was pretty much always random; destination port would be the port of the service, which is what normally happens in client/server scenario. It must be the way it's configged because we can only do SQL in AND out on a non-standard port on that box, so I'm confident this is how it works, based on previous experience).


phardacre

join:2004-01-19
UK

said by stoz:

In fact it has just been overtaken in priority though by the fact that downloads simply do not work! I've done ping -l -f to work out that our max packet size is 1436, so I've tried setting 'ip mtu 1436' accordingly, as well as varying 'ip tcp adjust-mss' values. This is pretty crucial, and I'm trying to fix it before anyone notices, but obviously we need downloads working ASAP!

What sort of downloads are you having issues with? Standard HTTP ones or FTP? Is anything reported in the logs? Your MTU should be 1492 on the Dialer interface for PPPoE. I don't see the ip tcp adjust-mss 1452 on the dialer1 interface in your config.

On mine I can successfully ping up to 1464 bytes with an MTU 1492 and MSS of 1452. This fits in perfectly with the values at »/tweaks/MTU/.

said by stoz:

EDIT: the reason I'm not having any luck is probably because our web server doesn't have 1723 open, for inbound, and doesn't let anything out through that port either (this always confused me because I thought that source port was pretty much always random; destination port would be the port of the service, which is what normally happens in client/server scenario. It must be the way it's configged because we can only do SQL in AND out on a non-standard port on that box, so I'm confident this is how it works, based on previous experience).

That would explain why nmap and shields up were seeing the port as open. So testing the VPN from somewhere else would probably work.

Cheers,

Paul

stoz

join:2012-03-13

1 edit

I think I may be getting slightly confused with the MTU values. I've set them subsequently to posting the config, which is why they aren't showing up. I found a few posts on Google where people had done similar to me, and stated that you had to match the MTU to the packet size you settle on doing ping -l -f. It doesn't seem to have made any difference.

For clarity should I just set MTU 1492 on Dialer 1 and MSS 1452 on Dialer 1 too? Do I need to set the MSS on any of the VLAN interfaces?

Oh I tested the VPN from home last night it works fine. I realise now that testing it from the web server doesn't work (1723 isn't opened) and nmap and shields up were correctly reporting that the port is open.

Edit: additionally I find that if I disable the Cisco FW downloads work fine. We can surf the net with the FW up, but no downloads or speed test Not sure what in the FW might be blocking it, but imagine maybe it isn't necessarily specific to using PPPoE like this scenario...


phardacre

join:2004-01-19
UK

You should just need to set them on Dialer1 as that's where the limitation is. Other traffic can use a higher MTU and anything going over the Dialer1 interface should automatically get it's MSS lowered to the correct value in the SYN packet.

Given that your downloads work with the firewall off, it's pointing to a problem with the firewall inspection. My guess is you need to add match protocol http to the sdm-cls-insp-traffic class-map.. Make sure you add it before the match protocol tcp

Cheers,

Paul


stoz

join:2012-03-13

Ok great I'll give that a go. Many thanks again Paul.


stoz

join:2012-03-13
reply to phardacre

Right well I got somewhere by moving the match http rule above the sdm-class-inspect-traffic rule in the SDM - speedtest got a bit further, but slower than normal, before eventually erroring out. Back to the drawing board I guess.


phardacre

join:2004-01-19
UK

Just out of curiosity, what speedtest are you using? I've just started using »www.measurementlab.net/run-ndt which seems to be quite good, can give you some useful info. What errors are you getting? Does anything pop up in the console logs on the router?

You're doing a lot with that router so it could be that it's CPU is maxed. As I said, ours will top out at ~30Mbps downstream just doing NAT - no ZBF at the moment. If it's gotta inspect all the packets coming in as well, I'd expect that to add more load. Try a sh proc cpu history and see what the cpu loads are like. Though, saying that, I'd expect it to just get slower rather than cause a connection to drop if the cpu load was causing the problem..

Cheers


stoz

join:2012-03-13

I normally just use speedtest.net (37.99 down / 9.00 up)
I had a go with the site you linked and got 37 down / 9 up. I can post the details too but they dont seem amiss.

If you're just using NAT on the router what're you using for the ZBF? Another Cisco or proxy server? NAT on our router is working fine, although non-used ports are closed rather than stealthed. The speed is absolutely fine too, it's only when we enable basic FW that we run into problems.