Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 1664 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPsec has Exchange and Terminal Services issues

Jason_Walker
I am trying to create a IPsec tunnel between 2 Astaro's I have. One is at my house the other is at my office. I have created the tunnels and some traffic works fine. The problem I have is that I cannot access my Exchange server, and I cannot Terminal Service to machines accross the tunnel. I seem to remember having this issue before, and what it ended up being was a TCP MSS setting on one of the tunnel endpoints (it was a Netscreen). fwiw, windows shares seem to work fine over the tunnel. My home end of this tunnel is DSL with PPPoE, the Office end going into a cisco router and through a T1. Any thoughts on this?  I have already tried to add a iptables rule on both sides that looks like this:

iptables -I USR_FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

on both ends but to no avail. Is this even the right place to add such a rule? and will it be saved after a reboot?

If anyone out there has had this prolem before, let me know.

Jason  


This thread was automatically locked due to age.
Parents
  • 0
    Jason,

    this issue seems to be related to a wrong mtu on the DSL side. Some providers
    ovberride the default value.

    Please try to add 'mtu 1492' on top of /var/chroot-pppoe/etc/ppp/options and 
    in /var/chroot-pppoe/etc/ppp/options-default. Restart pppoe '/etc/rc.d/pppoe stop'
    and  '/etc/rc.d/pppoe start'

    Would like to get your feedback if that solves the problem.

    read you
    o|iver  
  • 0 in reply to oliver.desch
    Ok I tried that...doesnt seem to have changed it. I also tried that ppp mtu setting along with the iptables rule I posted, and still no dice. Any other ideas?  
  • 0 in reply to Jason_Walker
    When I've seen this problem, it has been an MTU issue.  I would suggest changing the MTU on the client machine because then your machine should never create a packet that needs to be fragmented (and certain protocols like FTP and IIRC, IPsec use the "Do Not Fragment" flag, so they will be dropped if the packets are bigger than any MTU size between your two hosts).

    When I've done this I usually set the MTU down to 1400 just to give myself plenty of room.  Your max MTU can be 1492 for DSL connections, but the IPSec header will also add additonal overhead, which is I why I always bump it down to 1400.

    If you are using a Windows Client, you can change the MTU by going into regedit and finding the key:

    HKey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

    Under Interfaces there will be a listing for each interface that will look something like {DA9837-38329-etc. etc.}.  Find the one that has the IP address value in it that has the correct IP address for your machine.  Once you have found your interface, create a new DWORD value, name it "Mtu" and make the value decimal 1400 (make sure that Mtu doesn't exist first, you may just be able to change it).  You will need to reboot to make the change take effect.

    This has always fixed my issues with Terminal Services over VPN connections.  Please let us know if that helps.
        
  • 0 in reply to Moby
    I have the same problem though only when connected with pptp. 

    It don't matter if I change the mtu on the client or the config files on the asl box, the ppp interface in Reporting/Network always gets "Mtu:1396" 

    Can I use some tool to debug this to see if it's really a mtu issue?

    Regards, Tony    
Reply
  • 0 in reply to Moby
    I have the same problem though only when connected with pptp. 

    It don't matter if I change the mtu on the client or the config files on the asl box, the ppp interface in Reporting/Network always gets "Mtu:1396" 

    Can I use some tool to debug this to see if it's really a mtu issue?

    Regards, Tony    
Children
No Data
Cookie Information Banner