3

Question

What is the minimum set of server and client configuration directives that I need in order to satisfy the following conditions?

  1. Virtual layer 2 ethernet network that will not be bridged with any other interfaces.
  2. VPN clients can exchange frames with any other VPN clients.
  3. DHCP is not required (No TCP/IP will be used within the VPN)
  4. All traffic on VPN will be ethernet brodcasts (no layer 3+ networking, in fact)
  5. The MTU of the virtual network needs to be much higher than that of the underlying networks and this should be transparent to the nodes within the VPN. OpenVPN is free to fragment packets outside of the VPN--I think this is enabled via the fragment and tun-mtu directives. The overhead of using these options is not a concern. (target MTU is 2360)
  6. Security of the network is not a concern--its purpose is strictly to be a completely in-software ethernet link for nodes that are not physically near each other.

What work have I already done?

I have a lot of experience with OpenVPN, so I'm fairly confident that I have the basics covered. However, I cannot seem to nail down the large MTU size requirement. Clients on the VPN can connect and if I configure TCP/IP for testing, all clients can ping each other except when ping testing with do-not-fragment and packet size higher than 1472. The logs do not reveal anything obvious.

Please see the following configuration files.

server config:

mode  server
port  1195
proto udp
dev   tap

tun-mtu 2360
fragment 1500

comp-lzo
max-clients 200
client-to-client

ca     special-net/ca.crt
cert   special-net/sn-server.crt
key    special-net/sn-server.key
dh     special-net/dh1024.pem
status special-net/status.log
tls-server
tls-auth ta.key 0
auth-user-pass-verify /bin/true via-env
duplicate-cn
username-as-common-name

user nobody
group nogroup
persist-key
persist-tun
verb 4

client config:

client
remote <redacted> 1195
proto udp
dev tap

tun-mtu 2360
fragment 1500

ca             special-net/ca.crt
cert           special-net/sn-client.crt
key            special-net/sn-client.key
tls-auth       special-net/ta.key 1
auth-user-pass special-net/user.txt
ns-cert-type server

nobind
user nobody
group nobody
persist-key
persist-tun
comp-lzo
verb 3
resolv-retry infinite

Why am I doing weird things with OpenVPN?

I need a way to distribute (as opposed to a simple capture) raw 802.11 frames as they are observed by listening posts. I intend to accomplish this by having the listening posts transmit each 802.11 frame as-is to the VPN, but with an ethernet header prepended. The ethernet header will simply be an ethernet broadcast that OpenVPN will then distribute. The maximum frame size for an 802.11 datagram is 2346 octets, that makes my desired MTU 2360 (14 additional bytes for the ethernet header).

2
  • This might be a silly question, but is your OpenVPN binary compiled with ENABLE_FRAGMENT defined? Jul 9, 2013 at 1:26
  • @EvanAnderson I was using whatever was provided by the debian distribution. I was able to solve this problem by adjusting the MTU on the tap interfaces (see my answer below). Thanks for your input. Jul 9, 2013 at 13:41

1 Answer 1

1

Inspiration came overnight. It seems that the tun-mtu directive merely informs OpenVPN about the MTU and does not cause OpenVPN to set the MTU on the tap device itself. Setting the MTU on the tap interfaces manually enabled the VPN clients to send and receive packets without fragmentation up to the full 2360 bytes as I required.

I set the MTU directly using ip link set tap0 mtu 2360 at each client and the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .