[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Incorrect tcp and udp checksums on packets from gateway to vpn clients (solved)


  • Subject: Re: [Openvpn-users] Incorrect tcp and udp checksums on packets from gateway to vpn clients (solved)
  • From: "Giampaolo Carmagnani" <giampaolo@xxxxxxxxx>
  • Date: Mon, 2 Apr 2007 21:30:49 -0300

On 4/2/07, Georg Graf <g.graf@xxxxxxxx> wrote:
> Hello everyone,
>

Hello Georg
> This relates to OpenVPN with FreeBSD and is (mostly) solved, see below:
> Maybe its something for the FAQ ...
>
> I've got a quite simple and vanilla config here. There is an office
> network (10.10.10.0/24), and a DSL Internet Uplink. Ovpn clients connect
> to the external IP, port 1194 udp, of the Firewall (FreeBSD 6.2 RELEASE
> / i386). Ovpn is configured to use the tap Interface. The setup works
> very nicely.
>
> Smtp and imap services are running on the inside Part of the Firewall,
> which is also the openvpn Server, at 10.10.10.1. Machines on the "wired"
> office part of the LAN can connect to these services, but ovpn clients
> cannot. They can ping 10.10.10.1 but tcp and udp do not work.
>
> To be more specific, TCP packets sent by the firewall to the vpn clients
> have corrupted checksums, thats what tcpdump tells me. Unfortunately I
> have no Idea whether it's an OpenVPN or FreeBSD Bug, but certainly it is
> one.
>
> This tcpdump explains my Problem:
>
(snip)

> Server Config:
> | mode server
> | float
> | local 81.223.15.212
> | push "dhcp-option DNS 10.10.10.15"
> | push "dhcp-option DOMAIN office.celix.at"
> | push "ip-win32 dynamic"
--ip-win32 method
    When using --ifconfig on Windows, set the TAP-Win32 adapter IP
address and netmask using method. Don't use this option unless you are
also using --ifconfig.

> | crl-verify crl.pem
> | port 1194
> | proto udp
> | dev tap
> | ca ca.crt
> | cert server.crt
> | key server.key  # This file should be kept secret
> | dh dh2048.pem
> | ifconfig-pool-persist ipp.txt
> | server-bridge 10.10.10.70 255.255.255.0 10.10.10.71 10.10.10.89
> | keepalive 10 120
> | comp-lzo
> | max-clients 15
> | user nobody
> | group nobody
> | persist-key
> | persist-tun
> | status openvpn-status.log
> | verb 1
>
> Client Config:
> | client
> | dev tap
> | pull
> | proto udp
> | remote ssl.celix.at 1194
> | resolv-retry infinite
> | nobind
> | persist-key
> | persist-tun
> | ca ca.crt
> | cert celix.crt
> | key celix.key
> | ns-cert-type server
> | comp-lzo
> | verb 1
>From FAQ:

"I can ping through the tunnel, but any real work causes it to lock
up. Is this an MTU problem?

Probably. It's best to change the mssfix parameter rather than
directly changing the MTU of the TUN/TAP adapter. For example:

    mssfix 1200

You could also combine this with:

    fragment 1200

Note however that fragment will exact a performance penalty.

Common values to try for mssfix/fragment: 1200, 1300, or 1400.

Note that while mssfix only needs to be specified on one side of the
connection, fragment should be specified on both."

This is most happen when the server is *nix based and the clients are
windows based.

Regards.

Giampaolo Carmagnani

>
> /etc/sysctl.conf
> | net.link.ether.bridge.config=em0,tap0
> | net.link.ether.bridge.enable=1
>
> /boot/loader.conf
> | ipdivert_load=yes
> | bridge_load=yes
>
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users