Cisco 857 stops users from sending Outlook email

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hello,
I recently put a Cisco 857 on my network for creating client-to-site VPNs, a learning exercise more than anything during a quiet summer. I eventually got the VPN set-up and working with Cisco VPN client software, but have gone back to scratch with the config because issues prevail. Setting up was no particular drama (apart from some routing issues) and getting online and sending mail from some machines (5 in total) using Outlook works fine, but 2 machines can't send email using Outlook - but they can receive, nor can they use Windows Update online. If I use thunderbird on those 2 machines, they can send mail but can't send attachments. If I take the 857 out of the equation and use my noddy SmartATX modem again, I have no problems with mail on the 2 machines in question. On the machines in question, and my little LAN in general, DNS has been shown to work fine when I queried it using nslookup, I already had a reverse zone set up with a pointer to my internal dns server.

I was hoping to get a working config, save it, make sure Outlook worked properly on the 7 machines and then re-describe the VPN in the config. Yet despite reading a wealth of links and having a Onenote page heaving with pasted config lines from various sites, I'm no closer to sorting it, so was hoping someone could help out. Many thanks in advance.
Config below:

version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname WRS
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 debugging
logging console critical
enable secret 5 $1$BFYi$AmW.97vm6u15Yba4izjoG.
!
aaa new-model
!
aaa authentication login local_authen local
aaa authorization exec local_author local
!
aaa session-id common
!
resource policy
!
clock timezone PCTime 0
clock summer-time PCTime date Mar 30 2003 1:00 Oct 26 2003 2:00
no ip source-route
!
ip cef
ip inspect name DEFAULT100 cuseeme
ip inspect name DEFAULT100 ftp
ip inspect name DEFAULT100 h323
ip inspect name DEFAULT100 icmp
ip inspect name DEFAULT100 rcmd
ip inspect name DEFAULT100 realaudio
ip inspect name DEFAULT100 rtsp
ip inspect name DEFAULT100 esmtp
ip inspect name DEFAULT100 sqlnet
ip inspect name DEFAULT100 streamworks
ip inspect name DEFAULT100 tftp
ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 udp
ip inspect name DEFAULT100 vdolive
ip tcp synwait-time 10
no ip bootp server
ip name-server 208.67.222.222
ip name-server 208.67.220.220
ip ssh time-out 60
ip ssh authentication-retries 2
!
!
crypto pki trustpoint TP-self-signed-63753999
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-63753999
revocation-check none
rsakeypair TP-self-signed-63753999
!
crypto pki certificate chain TP-self-signed-63753999
certificate self-signed 01 nvram:IOS-Self-Sig#391B.cer
username WRS privilege 15 secret 5
username steve privilege 15 password
!
interface Null0
no ip unreachables
!
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
ip route-cache flow
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
description $ES_WAN$$FW_OUTSIDE$
no ip redirects
no ip unreachables
no ip proxy-arp
no snmp trap link-status
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Vlan1
description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$$ES_LAN$$FW_INSIDE$
ip address 192.168.200.251 255.255.255.0
ip access-group 102 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ip route-cache flow
ip tcp adjust-mss 1452
!
interface Dialer0
description $FW_OUTSIDE$
ip address negotiated
ip access-group 101 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1458
ip inspect DEFAULT100 out
ip nat outside
ip virtual-reassembly
encapsulation ppp
no ip route-cache cef
no ip route-cache
no ip mroute-cache
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname
ppp chap password 7
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip http server
ip http access-class 3
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source list 1 interface Dialer0 overload
!
logging trap debugging
access-list 1 remark INSIDE_IF=Vlan1
access-list 1 remark SDM_ACL Category=2
access-list 1 permit 192.168.200.0 0.0.0.255
access-list 2 remark Where management can be done from
access-list 2 remark LAN, VPN, Nathan home, Ste home, Ste work
access-list 2 permit 192.168.200.0 0.0.0.255
access-list 2 permit 192.168.250.0 0.0.0.255
access-list 2 permit 90.195.55.0 0.0.0.255
access-list 2 permit 87.194.146.0 0.0.0.255
access-list 2 permit 212.158.45.0 0.0.0.255
access-list 3 remark HTTP Access-class list
access-list 3 remark SDM_ACL Category=1
access-list 3 permit 192.168.200.0 0.0.0.255
access-list 3 deny any
access-list 101 remark Traffic allowed to enter router from Internet
access-list 101 remark SDM_ACL Category=1
access-list 101 permit udp host 208.67.220.220 eq domain any
access-list 101 permit udp host 208.67.222.222 eq domain any
access-list 101 permit icmp any any echo-reply
access-list 101 permit icmp any any time-exceeded
access-list 101 permit icmp any any unreachable
access-list 101 permit udp any any eq non500-isakmp
access-list 101 permit udp any any eq isakmp
access-list 101 permit esp any any
access-list 101 permit ahp any any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip host 255.255.255.255 any
access-list 101 deny ip host 0.0.0.0 any
access-list 101 deny ip any any
access-list 102 remark Traffic allowed to enter router from ethernet
access-list 102 permit ip 192.168.200.0 0.0.0.255 any
access-list 102 permit ip any host 192.168.200.251
access-list 102 permit ip any host 255.255.255.255
access-list 102 deny ip any any log
dialer-list 1 protocol ip permit
no cdp run
!
control-plane
!
banner login ^CAuthorized access only!
Disconnect IMMEDIATELY if you are not an authorized user!^C
!
line con 0
login authentication local_authen
no modem enable
transport output telnet
line aux 0
login authentication local_authen
transport output telnet
line vty 0 4
access-class 2 in
authorization exec local_author
login authentication local_authen
transport input telnet ssh
!
scheduler max-task-time 5000
scheduler allocate 4000 1000
scheduler interval 500
end

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

So two machines can't send using Outlook, but the other 3 can?

Any differences between the machines? IP addresses, gateways, DNS, OS, anything?

 

That's the thing, it's just so weird. Everything is the same, the 857 is the only gateway, the internal DC is the both the DHCP server and DNS server. The DNS server forwards its requests to OpenDNS as the next hop. The OS are all XP, but SP2 or 3 makes no difference. Outlook 2003 or Outlook 2007 makes no difference. Statically addressing them makes no difference. The fact that Thunderbird can send when Outlook can't is just alien to my brain. But then Thunderbird chucks up an error when trying to send attacments, no matter how small, like 1KB. It makes me wonder if the DC is wrong somewhere, but my machine operates on DHCP from the DC just like the 2 machines that have the problems - yet I have no trouble. The second the 857 is removed from it's gateway position by putting the ADSL cable back into the SmartAX modem and reassigning the router in DHCP, the problems go away.
It beats me!

 

And everyone's e-mail accounts are hosted similarly? Same external provider, no Exchange, right?

Let's say UserA's PC is one that can send Outlook e-mail and UserB's PC is one that cannot. Have you tried logging into UserB's PC as UserA, configuring up his e-mail in Outlook, and trying it (and similarly, UserB on UserA's PC)? That'll help you determine whether it's possibly a user problem or a computer/app problem...

 

My money is on your esmtp inspection, have you checked your logs?

 

Are you talking about remote clients with the Cisco VPN client - or is it site to site? Try checking your MTU settings - most issues with Outlook over VPNs are related to the MTU size - knock it down to 1390 or 1400 and see if that helps.

 

definately check the mtu, try sending a few pings off at various sizes and see what happens - the default SDM security config disables MTU path discovery by default, so you can end up sending packets that would need to be fragmented, but the router blocks the message back, so the client doesn't know and keeps trying to send packets too large. Had similar issue with cisco routers and VPN's ages back but can't remember the exact specifics - might be related to the 'no ip unreachables' command.

 

Ha after re-reading the post I think I got that a bit wrong never spotted the Windows update bit

 

Thanks for the sugestions so far.
Troubleshooting update:
The affected PCs can telnet onto the mail server without a problem (212.227.15.179)
Our email is hosted externally by 1and1, we access it using IMAP, requiring authentication to send, and over port 587.
I can't send email from my own mail account using the affected PCs
If I use another IMAP mail provider altogether, the new host we're migrating to, over port 25, I still can't send email from the affected PCs.
If I log on to the domain as myself on these PCs and set up my own mailbox, I can't send mail with Outlook.
Yet when I take the 857 out of the equation and connect the regular modem, the mails stuck in the outbox get delivered.
I've lowered the MTU to 1400 - no good.
I've added ip inspect name DEFAULT100 imap - no good.
I then acted on the comment about the no ip unreachables (which is only present in the config because of the SDM Security Audit) and BINGO - I can now send mail from the 2 awkward PCs! And that was because of Nutsy's hunch. Nutsy I owe you a favour

Can anyone help me understand why though? Why did the no ip unreachables statement affect only 2 PCs?
I found this on the web, but not sure it clears the water much

"• The fact that the ip unreachables command also affects sending of packet too big messages isn't even hinted at... The same goes for the description of the command in the command reference section. Only an ICMP Services Example explains a little more:
Disabling the unreachables messages will have a secondary effect—it also will disable IP Path MTU Discovery, because path discovery works by having the Cisco IOS software send Unreachables messages.
However, there still is no warning that disabling unreachables will make anything connected to links with reduced MTUs virtually unreachable, as nearly all hosts send all their packets with the DF bit set. And there are many people recommending "no ip unreachables": a Google search reveals this combination of words shows up, ironically, a little more than 1500 times.
There is a good use for this command, however: when a range of addresses is routed to the null interface, and "no ip unreachables" in configured for the null interface, any packets to the destinations in question will be dropped at the CEF level. Note that "no ip unreachables has affect on packets routed to the null interface, which is different from the behavior on other interfaces, where the command determines whether unreachables are sent back in response to packets received on the interface.

Pasted from <http://www.bgpexpert.com/archive2003q4.php> "

In the mean time, many thanks for the suggestions, I tried each of them in turn. I'll now save this config and keep it in a safe place, and put the VPN back on it this afternoon.
Warmest regards
Nathan

 

Its **** like this that makes me glad I chose to pursue systems and not networking. From my limited knowledge of setting up Cisco gear it seems they are prone to making arbitrary decisions like this (SMTP Fixup anyone?) and implementing them in default SDM/PDM configs - leaving people to figure out on their own why something that should work doesn't - all because some engineer decided years ago that ICMP=insecure.

I've also encountered no end of trouble setting up site to site VPNs with Cisco gumph at one end when the other end wasn't - and never really had similar problems getting other vendors' devices to play with each other (Juniper, Checkpoint, Watchguard etc)

 

glad it helped - as to why it worked on some pc's and not others - can only think that perhaps the pc's that worked had a smaller MTU size set locally in the registry, so hence weren't sending packets that were too large - that or slightly different versions of outlook, maybe?

agree with the comment about SDM, and stupid obscure settings - when you dig a little deeper though, cisco kit remains some of the most configurable and flexible on the market, but SDM is rubbish and there are soo many headaches trying to set things up for the inexperienced. some of the stuff in IOS also dates back so far its obsolete and obscure, it could do with a complete rewrite really, but then perhaps you'd lose some of the flexibility.

My experience with multiple vendor IPsec VPN's - don't even bother. Stick to one vendor, it's really not worth the hassle! Standardised my ****.

 

LOL - try telling that to companies you're (ahem) 'integrating' with...

 

LOL - lets just not go there... how did we get from MTU to.... 'integrating' !!?