View Single Post
Old 9th October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 6,288
Default

I've taken a few minutes to look at the only network configuration information you have posted at this forum. In its entirety, this is:
  • The network interfaces in post #3 above
  • The PF configuration file attached to post #8 above
There are four things I am able to determine from this limited information.
  1. The network interfaces in post #3 match the hardware network interfaces posted in the PF configuration you attached to post #8. However the error message you posted in post#1 above will only produced when PF attempts to obtain the Maximum Transmission Unit (MTU) size of a non-existent interface.

    The PF configuration includes references to a network tunnel pseudo-device, tun3. This device exists on your "old" system, but not your "new" system.
  2. The PF configuration includes rules for BOTH IPSec and OpenVPN. Your reference in post #7 to OpenVPN was not a typo. It is the OpenVPN rules which refer to tun3.

    Both IPSec and OpenVPN are VPN technologies, but they are otherwise entirely unrelated.

    OpenVPN is not part of the OS kernel. It is a "userland" program, that communicates with the kernel's network stack via a network tunnel pseudo-device.

    The tun(4) driver was split in two for OpenBSD 5.9. The tun(4) driver became a point-to-point connector only, and a new driver, tap(4), took on the responsibility for tunneling Ethernet frames between the kernel and userland programs. OpenVPN connections may use tun(4) or tap(4) depending upon how they are provisioned.
  3. If you want your replacement gateways to pass OpenVPN traffic, you will need to install and configure the OpenVPN package. At 6.0 this is version 2.3.11 of OpenVPN. At 5.3, the version was 2.2.2.

    If you install this package, please read the pkg-readme file which installs with it. It explains the replacement of the tun(4) driver with the tap(4) driver for tunnelled Ethernet if required.

    If you do not want or need OpenVPN, remove the rules related to this traffic from your PF configuration.
  4. Your PF configuration broadly passes both IPSec and OpenVPN traffic indiscriminately (any to any), and does not filter it in any way.

    The IPSec traffic will use IPSec's Encapsulating Security Payload (ESP) protocol. This protocol is always passed.

    The IPSec traffic is presented to PF in plaintext via the enc(4) pseudo device for filtering. This traffic is always passed.

    The OpenVPN traffic is tunnelled via User Datagram Protocol (UDP) packets with source 1194 and destination port 1194. This traffic is always passed.

    The OpenVPN program-to-network traffic is sent and received via pseudo device tun3. This traffic is always passed.
You may recall my whining, more than once, that we can only help you based on the information you present to us. I'm whining again, because until I looked at this configuration file I was unaware you had two different VPN technologies deployed.

Last edited by jggimi; 9th October 2016 at 03:22 AM. Reason: clarity
Reply With Quote