Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 2 subscribers
  • Views 7870 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

PPTP/PPPoA and Policy Routing, MTU issue?

x-cimo
I have a NIC set as a PPPoA/PPTP tunnel that connect to a PPTP VPN at my ISP (only way to get static IP from them). The MTU on it is 1500, also my WAN is Cable with MTU = 1500
The VPN "works".

To test it out I have setup a Policy Route such as:

Type: Interface route
Source network: my laptop host
Services: Any
Destination network: Internet
Target Interface: PPPoA VPN Interface

This work pretty well for ping, internet download etc, however I noticed two things:

1) Some website partially load or load forever, wireshark show a HTTP GET then a ACK back and nothing else.

2) I sometime see the message: "ICMP Fragmentation Needed"

Any ideas?

Thanks!


This thread was automatically locked due to age.
  • 0
    I bet you're right.  Try an MTU of 1478. If that doesn't work, then drop down to 1450 and work up from there.

    Any luck?
  • 0 in reply to BAlfson
    It didin't seem to help, any other ideas?
  • 0
    Is this a new NIC and/or second connection to your ISP?

    Cheers - Bob
  • 0 in reply to BAlfson
    The setup is weird but here it is:

    ASG has 3 Physical NIC:

    1) WAN (Cable modem to ISP: MUT 1500)
    2) LAN 
    3) NIC setup as PPPoA, this nic is connected my LAN switch (same as LAN NIC #2) 

    So the PPTP traffic end up on my LAN and then go out on WAN (The only physical NIC that goes on the internet).

    I have 2 Policy Routing rules,

    1) State  that all traffic going to the IP of the PPTP VPN server must go over the WAN interface (because otherwise the PPTP traffic ended up by trying to go over the PPTP (PPPoA) interface which caused an infinite loop of high cpu usage and bandwidth and tunnel disconnecting.

    2) the rule above, stating that one host go over the PPPoA interface.

    The PPTP tunnel seem reliable, it doesen't disconnect or anything.

    Ping works fine, most website work fine, but some half load (mostly when trying to get to other website such as for a Ads etc), i.e AMD.com work fine, but when trying to download a file (from a different hostname.amd.com, the file dosen't start even if tried many times.

    However for site that works the throughtput is good, (I can get 30Mbps on speedtest website).

    I understand that this is a complicated setup, that shouldn't exist, but it does something that ASG dosen't do.. (Client VPN connection..)
  • 0 in reply to x-cimo
    a friend suggested that I set PPPoA interface to 1492 (default), WAN: 1500,

    and set my workstation MTU (for testing) to something low, since MTU are negotiated at TCP establishment.

    If that fix the issue, try looking at TCP MSS clamp:

    iptables -A OUTPUT -o ppp+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
    --clamp-mss-to-pmtu
    iptables -A FORWARD -o ppp+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
    --clamp-mss-to-pmtu

    Aparently if my workstation sends IP fragment at a MTU of 1500, the PPTP flagment it, however the data coming back might not be and gets dropped..
  • 0
    a friend suggested that I set PPPoA interface to 1492 (default), WAN: 1500,

    That was what I was trying to say, but was confused by your setup.  When you initally configured the PPPoA interface, it should have given you 1492, so that's why I suggested 1478.  You should do this in WebAdmin instead of at the command line.

    If that doesn't resolve your issue, then I would try different combinations of fixed speed and full/half-duplex in the Hardware settings for the PPPoA interface.

    Cheers - Bob
  • 0 in reply to BAlfson
    Thanks for helping,  I've tried the following:

    I had a extra Intel NIC e1000 unused in the machine so I setted up the PPPoA on that interface instead of the realtek (onboard nic).

    I've set the mtu back to 1492. 

    But without success... This page seem to discribe my exact problem:

    Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users)

    I gave it a shot:

    with iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu 

    but It dosen't seem to work...
  • 0 in reply to x-cimo
    This worked!

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/18171

    I just typed this in ssh: 

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

    However I think it will be gone at next reboot, is there now a way to do this from the GUI ? or add it to a file somewhere...

    The /etc/rc.d/ipfilter.local  mentionned in the thread dosen't exist anymore.. and that thread if from 2003 [:)]
  • 0
    Isn't that done to set the MTU to a lower value?  Why didn't that work from the 'Advanced' section of the PPPoA/PPTP 'Interface' definition?

    Cheers - Bob
  • 0 in reply to BAlfson
    Wow! I'm happy I can maybe make you learn something today, here is what I understood from it.

    MTU Path discovery dosen't work that well, for many reason apparently.

    Another way to archive similar result is by teaching iptables to modify the advertised Maximum Segment Size at the TCP layer (so a TCP packet dosen't exceed "X"),

    TCP MSS: The TCP/IP Guide - TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size

    Basically by limiting the MSS at TCP, it limit the size at the IP layer (MTU).

    This is what the iptables rule above does..

    And I seem to have found the proper place to implement this in a different thread:

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39700