Hi Ian
The ipsec is also interesting but right now the problem is our customers have "local" internet access so what we are looking at is a setup where we are running on a idle router which has a ADSL with 20 mbps down and 10 mbps up - and in the actual case the customer can run a internet based speedtest (http://tdc.dk/hastighedstest - based on ookla's flash-based speedtest-module) where he - when he is behind the router - can get around 10 mbps down and 8 mbps up - and if he removes the router and put his PC directly on the net he is up around the expected numbers ~ 19 mbps down and 9 mbps upload. Is this expected?
We have inspect enabled:
!
ip cef
ip inspect max-incomplete high 1100
ip inspect max-incomplete low 1100
ip inspect one-minute high 1100
ip inspect one-minute low 1100
ip inspect name ourfw tcp
ip inspect name ourfw udp
ip inspect name ourfw cuseeme
ip inspect name ourfw ftp
ip inspect name ourfw h323
ip inspect name ourfw rcmd
ip inspect name ourfw realaudio
ip inspect name ourfw smtp
ip inspect name ourfw streamworks
ip inspect name ourfw vdolive
ip inspect name ourfw sqlnet
ip inspect name ourfw tftp
ip inspect name ourfw rtsp
ip inspect name ourfw netshow
ip inspect name ourfw fragment maximum 256 timeout 1
ip inspect name ourfw http java-list 80
and running a simpel NAT:
ip nat inside source list 175 interface FastEthernet4 overload
where the access-list 175 just defines a few networks denied which is going though a VPN and the rest permitted directly - and here is the Fastethernet4:
interface FastEthernet4
ip address dhcp
ip access-group acl_103 in
ip inspect ourfw out
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
crypto map cm-our
I'll try to disabled the inspect part to see if this gives us any difference. The white paper looks a bit optimistic to me...
