Andrew_Wallbank
asked on
Sending E-Mails with attachments through Cisco VPN fails
We have an IPSEC site-to-site VPN between a Cisco 850 router and a Cisco VPN Concentrator.
Clients are able to browse the Internet and receive e-mail, carry out DNS lookups etc but are unable to send e-mails with attachments. E-Mails without attachments are going OK, but anything with an attachment times out.
The VPN is set to tunnel all traffic, with the hosts specified on the Router and the Concentrator. I can see the POP3 and SMTP traffic on our Firewall logs when the clients attempt to download and send e-mail.
I have tried changing the MTU size on the router for the Dialer interface from 1500 to 1458 (as recommended in a number of Cisco documents) and to 1400 (to see if it made any diference at all), but there is no change, e-mails with attachments fail.
The ADSL speed is only 128k (not fantastic) but the same site had ISDN (so 64K) previously and this was sending fine. Using a different Mail client makes no diference, and trying to upload a file to a web-based mail system also fails.
After reading many articles on t'interweb it looks to be related to the MTU size, but having changed this I am now at a loss.
Has anybody else encountered any similar issues?
Clients are able to browse the Internet and receive e-mail, carry out DNS lookups etc but are unable to send e-mails with attachments. E-Mails without attachments are going OK, but anything with an attachment times out.
The VPN is set to tunnel all traffic, with the hosts specified on the Router and the Concentrator. I can see the POP3 and SMTP traffic on our Firewall logs when the clients attempt to download and send e-mail.
I have tried changing the MTU size on the router for the Dialer interface from 1500 to 1458 (as recommended in a number of Cisco documents) and to 1400 (to see if it made any diference at all), but there is no change, e-mails with attachments fail.
The ADSL speed is only 128k (not fantastic) but the same site had ISDN (so 64K) previously and this was sending fine. Using a different Mail client makes no diference, and trying to upload a file to a web-based mail system also fails.
After reading many articles on t'interweb it looks to be related to the MTU size, but having changed this I am now at a loss.
Has anybody else encountered any similar issues?
Personally I have an MTU of 1350 for all my remote locations, and no problems with attachments. Try lowering your MTU again and see what happens.
ASKER
Any reason why 1350? Is it something you have just picked up from experience or has it been recommended as a value you should use?
It's a historical value picked up from i took over the network. Having said that, with a lot of testing since I have found it to be a good value over vpn connections, especially for adsl.
ASKER
OK, thanks.
Changed to 1350, doesn't seemed to have worked, but I will get them to try a few more tests.
Forgot to say that Broadband service is 'BT Business Broadband'
Changed to 1350, doesn't seemed to have worked, but I will get them to try a few more tests.
Forgot to say that Broadband service is 'BT Business Broadband'
I'm on BT business broadband also, works for me. Maybe something server side ? but I can't help on that one i'm afraid...
ASKER
Looks like it isn't an issue with the service provider then, which is a relief at least.
Strange thing is, that uploading to a Webmail 'client' doesn't work either, so that would rule out the server, but not the Firewall or VPN terminator.
Strange thing is, that uploading to a Webmail 'client' doesn't work either, so that would rule out the server, but not the Firewall or VPN terminator.
What OS are you using on the clients? any possible update been done on the clients, blocking email attachments ?? From a router/vpn point of view it only see's ip traffic - it wont know there's an attachment there or not. I'd be looking at the client aswell.....just to rule it out.
ASKER
Windows 2000. Just been updated to SP4 to see if thjat resolved the issue, but it didn't. Think they were on SP2 before (I don't look after the clients).
Mail Client is Eudora (ver 4), but Outlook Express and Lotus Notes also fail.
I know that the router is only looking for IP traffic, it will in fact only deal with IP traffic to specific hosts (1 of them being the Destination server) and I can see this traffic being matched on the Access-list and on the Firewall at the remote end, so it looks like the connection is being established, but any e-mail with attachments does not get through. It's almost as like the mail is being rejected with the error 'Too much mail data', but it isn't, thats why I asked about the MTU value. Why should small E-Mails get through, but not one's with attachments?
1 of our server guys has tried sending a tiny attachment, only about 90bytes, and this has got through, anything bigger and it gets rejected.
Mail Client is Eudora (ver 4), but Outlook Express and Lotus Notes also fail.
I know that the router is only looking for IP traffic, it will in fact only deal with IP traffic to specific hosts (1 of them being the Destination server) and I can see this traffic being matched on the Access-list and on the Firewall at the remote end, so it looks like the connection is being established, but any e-mail with attachments does not get through. It's almost as like the mail is being rejected with the error 'Too much mail data', but it isn't, thats why I asked about the MTU value. Why should small E-Mails get through, but not one's with attachments?
1 of our server guys has tried sending a tiny attachment, only about 90bytes, and this has got through, anything bigger and it gets rejected.
Can you post the config of the remote site - sanitised of course....
The only thing now is to do a packet level debug on the remote with test emails, your 90byte mail gets through, but how big is too big ?
Once we have that particular value it may help track down the cause.
Do you have other sites - that can send/recieve attachments - you could compare the debug too?
The only thing now is to do a packet level debug on the remote with test emails, your 90byte mail gets through, but how big is too big ?
Once we have that particular value it may help track down the cause.
Do you have other sites - that can send/recieve attachments - you could compare the debug too?
ASKER
OK, here is the config for the Interfaces -
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
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 Vlan1
ip address
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
mtu 1350
ip address negotiated
ip access-group -> <-
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip route-cache flow
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname **username**
ppp chap password **password**
crypto map vpn
everything else is either access-list or crypto config.
I don't know how big is too big.
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
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 Vlan1
ip address
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
mtu 1350
ip address negotiated
ip access-group -> <-
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip route-cache flow
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname **username**
ppp chap password **password**
crypto map vpn
everything else is either access-list or crypto config.
I don't know how big is too big.
ASKER
ooops, clicked submit when i hadn't finished.
I don't know how big is too big, because we haven't been able to test this.
A basic notepad .txt file with about 1 word in goes out OK, but a word ;doc file with 1 word in does not. Yes there is plenty of rubbish in the document header for Word, but how much more?
I don't know how big is too big, because we haven't been able to test this.
A basic notepad .txt file with about 1 word in goes out OK, but a word ;doc file with 1 word in does not. Yes there is plenty of rubbish in the document header for Word, but how much more?
Hmm, try renaming the .txt file as .doc (word) see if that goes through. Just to rule out any file filtering by extension....worth a try i think.
ASKER
Can't think of any reason why there would be filtering on attachments (word documents can be downloaded), but I will give it a go.
ASKER
Found this -> http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml#pppoemtu
so have lowered the mss value to the lowest to see if it makes a diference, if it doesn't will try changing the value on the PC.
so have lowered the mss value to the lowest to see if it makes a diference, if it doesn't will try changing the value on the PC.
Andrew,
After looking through your interface configs again, you have "no ip unreachables" set.
IP unreachables is used in determining MTU path, see this link : http://www.bgpexpert.com/archive2003q4.php
Try setting "ip unreachables" on the interfaces and re-test. I have this enabled in my config and dont get issues with attachments of any size.
After looking through your interface configs again, you have "no ip unreachables" set.
IP unreachables is used in determining MTU path, see this link : http://www.bgpexpert.com/archive2003q4.php
Try setting "ip unreachables" on the interfaces and re-test. I have this enabled in my config and dont get issues with attachments of any size.
ASKER
That makes a lot of sense. A good read.
I have changed the 'no ip unreachables' to 'ip unreachables' , lets see if it makes any diference. Tried to contact the remote site, but no answer. . . so watch this space.
I have changed the 'no ip unreachables' to 'ip unreachables' , lets see if it makes any diference. Tried to contact the remote site, but no answer. . . so watch this space.
ASKER
Unfortunately this did not work.
The MTU is now set to 1350 and the command 'IP unreachables' is set on the dialer interface.
trinak, you said that the enabled on your config, but is it on all interfaces or just the dialer/outbound interface?
The MTU is now set to 1350 and the command 'IP unreachables' is set on the dialer interface.
trinak, you said that the enabled on your config, but is it on all interfaces or just the dialer/outbound interface?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK.
ip unreachables is now on all the interfaces, will have to wait until tomorrow to check though.
Keepalives is on.
ip unreachables is now on all the interfaces, will have to wait until tomorrow to check though.
Keepalives is on.
ASKER
Looks like that was it.
I have received an attachment this morning, and they can successfully browse a website they were having trouble with last week before I made the change.
I have asked them to run a few more tests, but it looke like that was the solution. Thanks Trinak
I have received an attachment this morning, and they can successfully browse a website they were having trouble with last week before I made the change.
I have asked them to run a few more tests, but it looke like that was the solution. Thanks Trinak
That's excellent news....hope the testing is successfull, if not just let me know and we'll think of a plan B !
ASKER
testing went well. I have now received a 3mb Word attachment.
It could have been a combination of the MTU value AND the ip unreachables, but it didn't work until the ip unreachables on all interfaces was configured,
I have marked that as the solution, as it needed to be configured on all Interfaces.
It could have been a combination of the MTU value AND the ip unreachables, but it didn't work until the ip unreachables on all interfaces was configured,
I have marked that as the solution, as it needed to be configured on all Interfaces.