-2

I connected an Postfix/Dovecot smtp server through an OpenVPN tunnel to an VPS to the Internet. When i send short (like 3-4 sentences) emails using my regular internet connection to it (Port 587), it works fine. But if my emails are longer, Thunderbird throws an connection lost in middle of transaction error. If i connect my machine to the same VPN&VPS, sending works just fine. All machines are running Dual Stack, also the the VPS & OpenVPN tunnel (using tun, no tap). Receiving long emails from other email-servers works just fine. How can i fix the issue? All servers are running on Debian 9, Client is running Win10.
Thi issue arises on IPv6 only. So far i've only tested it from my home network. tun-mtu is set to 1280 now. tracepath correctly recognizes the set MTU.
Here are my ip6tables:

# Generated by ip6tables-save v1.6.0 on Tue Mar 27 23:51:39 2018
*filter
:INPUT ACCEPT [5:608]
:FORWARD ACCEPT [1217:402964]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
-A FORWARD -s [MYSUBNET]/64 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p ipv6-icmp -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -j ACCEPT
COMMIT
  • 1
    Sounds like it might be MTU related; the smaller e-mails may not result in a packet large enough to fail, but larger ones do. I don't know enough to suggest a specific change you can make to fix it, hence this being a comment not an answer. Maybe mssfix in your openvpn config, or somthing similar? – Craig Miskell Mar 27 '18 at 06:33
  • i have `tun-mtu 1300 mssfix 1240` in both client and server config file, still nothing changed. I'll try @kostix's solution now. It may be MTU related, Wireshark tells me that the packets via VPN are 1240 bytes big (maximum) while sending them without VPN results in a packet size of 1440 bytes – KaitoCross Mar 27 '18 at 20:35
  • I had the same issues with my webserver which is connected in the same way. before applying `tun-mtu 1300 mssfix 1240` to the config files. The tun-mtu and mssfix seem to fix at least that issue. – KaitoCross Mar 27 '18 at 20:55

1 Answers1

1

I'm with @CraigMiskell on this: if P-MTU is broken in your network (due to inherent "anisotropy" of IP network, it may be broken in one direction but not the other), this may result in big IP segments being dropped somewhere in the middle with ICMP messages about that not reaching your stack back. Try starting here.

Another possibility may be that you are overly defensive in the settings of whatever thing firewalls your private network. Say, with the Linux's Netfilter people tend to have something like

iptables -L INPUT -P DROP
iptables -L INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

(and ditto for FORWARD) — forgetting to also mention state RELATED in that "enabling" rule — and hence forbidding for ICMP messages related to a TCP connection to reach the local network stack.

Check you wasn't overly restrictive on this front.

Things to learn about: P-MTU, P-MTU discovery, ICMP "can't fragment" message, TCP MSS.

kostix
  • 1,100
  • 1
  • 7
  • 13
  • Just double-checked. It seems to have problems on IPv6. If i send emails through an IPv4 only mobile network, any size seems to be fine. My home networks uses IPv6 and IPv4, and since the email server & VPN server also use dual stack, the issue seems to be in the IPv6 connection from outside the VPN tunnel. iptables settings are fine in my setup. – KaitoCross Mar 27 '18 at 21:44
  • So, i've tried tracepath6 to see if it recognizes the tun-mtu value MTU, and is does apparently. Still nothing working. edited the post above to add my ip6tables. – KaitoCross Mar 28 '18 at 00:02